Intrusion Detection

Case StudyAuthors:

Martin ZaeffererYavuz Selim Inanir

Thomas Karanatsios

Institution:

University of Applied Sciences CologneFaculty for Informatics and Engineering

Program:

Master of EngineeringAutomation and IT

Matrikelnumber: 11053585Matrikelnumber: 11079711Matrikelnumber: 11032154

Examiner: Professor Dr. Frithjof KlasenUniversity of Applied Sciences Cologne

Gummersbach, February 2012

Abstract 2

Abstract

Flexible and increasingly open Ethernet based networks gain importance in automation indus-try. For that reason, intrusions into such networks become more and more a problem. It istherefore of major importance to be able to detect malicious activity in a network.

This report describes the results of a case study dealing with intrusion detection. It gives a gen-eral introduction into intrusion detection and an overview of related topics regarding IntrusionDetection Systems(IDSs). A number of possible vulnerabilities and attacks are introduced,focusing on lower layers of the ISO OSI model. This might be of a general interest becausethey do play an important role in an environment like industrial networks.

The practical part of this report is based on a small simulated network of virtual machines,where different penetration tests are done. This helps to figure out and to understand howsome typical attacks work and how they can be detected. A number of freely available soft-ware tools are used for starting simulated attacks and for detecting them. Classical IDSs areused for the detection, as well as specific configured Systems like Honeypots. In cases whereattacks were hard to detect, reasons are given and suggestions are made for future improve-ment on these issues.

The main goal of this case study is not to demonstrate well known attacks, but rather to showhow typical intrusion attacks work and how they might be detected. Different approaches fordetection are demonstrated to show that security can be increased significantly if more thanjust one line of defense is used. Another goal is to demonstrate how to set up a small pene-tration testing environment with virtual machines. Thus installation and setup information areprovided in this report. The advantage of such an environment is that attacks can be testedwith a minimum of resources and without having to compromise a real network, while testingvulnerabilities. On the other hand limitations are outlined as well, like the inability to test awireless medium in this environment.

List of Content 3

Contents

Abstract 2

List of Figures 5

List of Tables 6

List of Abbreviations 7

Task 8

Introduction 9

1 Basics 111.1 Intrusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Intrusion Detection Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.2 Information Sources . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.3 Database Types of Intrusion Detection Systems . . . . . . . . . . . . 131.3.4 Response of IDSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4 Intrusion Prevention Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4.1 Classifications of IDPSs . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5 Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5.1 Definition and further Details of Honeypots . . . . . . . . . . . . . . 16

1.6 Intrusion Detection Software . . . . . . . . . . . . . . . . . . . . . . . . . . 181.6.1 Honeypot Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.6.2 Further Defensive Tools . . . . . . . . . . . . . . . . . . . . . . . . 19

1.7 Penetration Testing tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.8 Attack Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.8.1 Layer 1 Based Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 221.8.2 Layer 2 Based Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 221.8.3 Layer 3 Based Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 241.8.4 Layer 4 Based Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 251.8.5 Layer 5++ Based Attacks . . . . . . . . . . . . . . . . . . . . . . . . 26

2 Testing Environment 272.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Virtual Machines setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3 Installation of used Software . . . . . . . . . . . . . . . . . . . . . . . . . . 30

List of Content 4

2.3.1 SNORT on windows . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.2 How to install suricata . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.3 How to install Snorby Security Distribution . . . . . . . . . . . . . . 332.3.4 Installing Metasploit Framework on Windows . . . . . . . . . . . . . 332.3.5 Installing Metasploit Framework on Ubuntu . . . . . . . . . . . . . . 342.3.6 Installing dsniff (Ubuntu) . . . . . . . . . . . . . . . . . . . . . . . . 342.3.7 Install Honeyd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.8 Install macchanger . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.9 Install xARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Test Cases 353.1 ARP Poisoning(Layer 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.1 Arp Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2 Mac Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3 DHCP Starvation (Layer 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.4 Reconnaissance: Scans and Sweeps (Layer 2,3,4) . . . . . . . . . . . . . . . 45

3.4.1 ARP sweep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.4.2 TCP port scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.4.3 UDP port scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.5 Detection with Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.6 SSL Man in the Middle attack . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 Summary 554.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 Forecast 575.1 False Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2 Statistical Anomaly-Based Intrusion Detection . . . . . . . . . . . . . . . . . 575.3 Additional Vulnerabilities of Interest . . . . . . . . . . . . . . . . . . . . . . 58

5.3.1 Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.3.2 Session Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Bibliography 62

List of Figures 5

List of Figures

Fig. 1.1: Example for NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Fig. 1.2: Example for HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Fig. 1.3: Example for Statistical Anomaly-based IDS . . . . . . . . . . . . . . . . 14Fig. 1.4: Example for Signature-Based IDS . . . . . . . . . . . . . . . . . . . . . 14Fig. 1.5: Example for Passive and / or (Re)-Active Systems . . . . . . . . . . . . . 15

Fig. 2.1: Network and software overview of testing environment . . . . . . . . . . 29

Fig. 3.1: Wireshark recording of an ARP attack . . . . . . . . . . . . . . . . . . . 37Fig. 3.2: Screenshot of xARP during ARP poisoning on ids1 . . . . . . . . . . . . 38Fig. 3.3: Screenshot in msfconsole for ARP poisoning . . . . . . . . . . . . . . . . 39Fig. 3.4: Screenshot of xARP during ARP poisoning on ids2 . . . . . . . . . . . . 39Fig. 3.5: Screenshot of wireshark during macof MAC-flooding . . . . . . . . . . . 40Fig. 3.6: Suricata alerts during MAC flooding . . . . . . . . . . . . . . . . . . . . 41Fig. 3.7: VB DHCP settings for starvation demo . . . . . . . . . . . . . . . . . . . 42Fig. 3.8: wireshark DHCP starvation a . . . . . . . . . . . . . . . . . . . . . . . . 43Fig. 3.9: wireshark DHCP starvation b . . . . . . . . . . . . . . . . . . . . . . . . 43Fig. 3.10: Wireshark DHCP starvation, no answer to new dynamic device . . . . . . 44Fig. 3.11: DHCP starvation result: No IP for ids2 . . . . . . . . . . . . . . . . . . . 44Fig. 3.12: ARP sweep with Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . 45Fig. 3.13: TCP scan with Metasploit, wireshark recording . . . . . . . . . . . . . . 46Fig. 3.14: TCP scan with Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . 46Fig. 3.15: Wireshark recording of UDP scan with Metasploit . . . . . . . . . . . . . 47Fig. 3.16: UDP scan with Metasploit, console screenshot . . . . . . . . . . . . . . . 47Fig. 3.17: Ping request and response to non existing IP with active honeyd and farpd 49Fig. 3.18: Wireshark recording and Metasploit outout during UDP scan with active

honeyd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Fig. 3.19: Honeyd ouput messages during UDP scan . . . . . . . . . . . . . . . . . 50Fig. 3.20: WEBMITM attack: ARP poisoning detected by xARP . . . . . . . . . . 51Fig. 3.21: Screenshot of dnsspoof and arpspoof tool . . . . . . . . . . . . . . . . . 52Fig. 3.22: Looking up a spoofed DNS on windows, nslookup and wireshark recording 52Fig. 3.23: Screenshot of webmitm tool, entering certificate information . . . . . . . 53Fig. 3.24: Certificate faked by webmitm in firefox . . . . . . . . . . . . . . . . . . 54

List of Tables 6

List of Tables

Tab. 1.1: Classifications of IDPSs . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Tab. 1.2: Commercial Intrusion Detection Systems and free Software . . . . . . . . 18Tab. 1.3: ARP Defensive Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Tab. 2.1: Network Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

List of Abbreviations 7

List of Abbreviations

ARP Address Resolution ProtocolCAM computer aided manufacturingDDoS Distributed Denial of ServiceDHCP Dynamic Host Configuration ProtocolDoS Denial of ServiceHIDS Host-based intrusion detection systemICMP Internet Control Message ProtocolIDPSs Intrusion Detection and Prevention SystemsIDSs Intrusion Detection SystemsIP Internet ProtocolIPSs Intrusion Prevention SystemsISO International Organization for StandardizationMAC Media Access Control AddressMSF Meta Sploit FrameworkNIDS Network-based intrusion detection systemOSI Open Systems InterconnectionS-B Signature-BasedSA-B Statistical Anomaly-BasedSSD Snorby Security DistributionSSL Secure Sockets LayerSYN SynchronizeTCP Transmission Control ProtocolUDP User Datagram ProtocolVLANs Virtual Local Area NetworksVPNs Virtual Private Network

Task 8

Task

This case study is supposed to examine Intrusion Detection, considering industrial networksas the area of application. Thus typical threats or events should be described in the study,examining how they can be analyzed and detected. Those incidents should have an impact onnetwork security and also be a concern in the specified area of application.

This could for instance include:

• Faked ARP messages

• Faked DHCP messages

• IP spoofing

• Sniffing and scanning

Testing these issues should be done as far as necessary to reproduce their main features. It isnot required for this study to reproduce real malicious behavior. Once identified it should beevaluated, if and how intrusion events can be detected. As one standard approach SNORT willbe tested for its ability to detect these events. Usage of the program and its rule sets will beexplained.Also other detection programs are to be introduced. The reason for introducing additionaldetection tools is, that SNORT can fail to recognize such events. If no approach to detecta certain intrusion event is found, it should be explained why. Suggestions should be maderegarding the future solution of such problems.

Introduction 9

Introduction

When protecting a network, three types of security systems should be used together. Firststructural security elements like firewalls should be employed. Secondly network traffic needsto be monitored and finally there should be an option for reacting to any kind of threats [NB04].With this case study we focus on the second part, as far as it is separable from the other two;“Intrusion detection”.The main focus of this report lies on industrial networks. As recent development in this arearequires more attention to intrusion threats than it received up to now.In [OSS11] several challenges to security of process control systems, which are an importantpart of automation solutions are mentioned:

• Opportunistic Predators:Opportunistic Predators includes threats like worms and viruses. While not intentionallytargeted, their frequent occurrence and wide spread makes them a dangerous threat.

• Targeted Attacks:These Attacks are designed for specific reasons and purposes aimed at a certain asset.For Example intentional sabotage or espionage.

• Regulatory Mandates:Regulatory Mandates are not a threat in itself but still a challenge. Especially if thecompany works highly regulated fields.

• New Technologies:The more rapid introduction of new technologies, even on process control levels, en-forces security measurements to close the gap.

While the fields of crime, espionage and sabotage with electronic systems seems to happenmore and more frequently, changes to the infrastructure of company networks, make themmore vulnerable to intrusion. The vertical integration of all levels of a companies IT infras-tructure means greater size, which makes it harder to supervise. But also raises the problemof possibly being accessible through external sources (e.g. internet, wireless, remote). It alsoraises problems of competence, between classical IT and operation staff.At the same time wireless access becomes more appealing for many companies, who use de-vices like PDA to do maintenance or similar tasks. That adds an additional source of intrusion,as wireless devices can be accessed without direct access to the IT infrastructure. Finally out-sourcing tasks to third vendors is also a problem. The reason for that is, that this increases thenumber of external devices, which could pose a threat to the IT infrastructure. This might beintentional (Targeted Attacks) or unintentional threats (Opportunistic Predators).In that way the increasing demand for visibility, interconnectivity and flexibility at the sametime leads to a demand of increased security. Therefore intrusion detection in industrial net-works deserves attention, as it can be an integral factor in network security.

Introduction 10

Recent media attention might be suspected to create an exaggerated panic, especially if criticalsystems are concerned. Still, Dzung et. al. [DNVHC05] has summarized some very realincidents. It was shown how compromised IT infrastructure can lead to real world damage.In this report the basics on intrusion detection and the related threats are elaborated in chap-ter 1. After this, in chapter 2 the scenario is introduced and an overview about the integratedsystems is given. The test cases related to this scenario are described in chapter 3. Finally theresults of this case study are summarized in chapter 4 and an outlook on future work is givenin chapter 5.

Basics 11

1 Basics

1.1 Intrusion

“An intrusion is a deliberate unauthorized attempt, successful or not, to break into, access,manipulate or misuse some valuable property and where the misuse may result into or renderthe property unreliable or unusable Intruders may be from outside the network or legitimateusers of the network.”[Kiz46] There are three known ways of Intrusion remote, physical orsystem intrusion.

1.2 Intrusion Detection

Techniques used to detect unauthorized access to a computer system or a computer networkare called intrusion detection. The main process of such a technique is to rate incidents ormessages and recognize, if they are common behavior of the watched system or network.Else intrusion detection has to determine, if incidents or messages are some kind of misuse inthe sense of an intrusion.[HLR92] Intrusion prevention on the other hand is the more activeapproach of actually preventing an unauthorized access of a system’s resources. There isan relation between the two processes. Intrusion detection is a passively working detectionsystem for intrusions, “intrusion prevention actively filters network traffic to prevent intrusionattempts”[Kiz46] there is also a little more detailed explanation later in this report.

1.3 Intrusion Detection Systems

1.3.1 Definition

Intrusion Detection Systems work as devices or software applications. Their main task is tomonitor network and system activities to find malicious activities or policy violations. Whensuch an event occurs it produces reports to a Management Station. The focus lies on identify-ing possible incidents, logging information about them and giving a report to the managementdevice.“IDSs are a necessary addition to the security infrastructure of nearly every organiza-tion.” [Sec11] It should be mentioned that some of the Intrusion Detection Systems may havethe possibility to stop an intrusion event but this is not the main task or even expected of amonitoring system. [Kiz46]

1.3.2 Information Sources

Intrusion Detection Systems(IDSs) can be dependent on different information sources or ar-chitectures. The following list shows the commonly used IDSs structures:

• Network Based Intrusion Detection Systems (NIDSs)

Basics 12

• Host Based Intrusion Detection Systems (HIDSs)

• Application Based Intrusion Detection Systems (APIDSs)

In the following subsections these different IDSs are explained.

Network Intrusion Detection Systems

A NIDS is an independent platform that identifies intrusions by examining network traffic andmonitoring multiple hosts. NIDSs gain access to network traffic by connecting to a networkhub, network switch configured for port mirroring, or network tap. In a NIDS, sensors arelocated at choke points in the network to be monitored, often in the demilitarized zone (DMZ)or at network borders. Sensors capture all network traffic and analyze the content of individualpackets for malicious traffic. In Fig. 1.1 you can see a typically built NIDS. An often usedSoftware example of a NIDS, is SNORT. [Wik11c]

Figure 1.1: Example for Network Intrusion Detection System

Host-Based Intrusion Detection System

A HIDS works with a software agent on a host. It identifies intrusions by analyzing systemcalls, application logs, file-system modifications (binaries, password files, capability databases,Access control lists, etc.) and other host activities and state. You can see in Fig. 1.2 how aHIDS is built. In fact there are also some application-based IDS which a part of this category.One good example is OSSEC [OSS11] which is a open source IDS.

Basics 13

Figure 1.2: Example for Host-Based Intrusion Detection System

Application-Based Intrusion Detection Systems

APIDSs are tied to a certain application, monitoring status and behavior of that one single partof a system. An example for this is for instance secerno (http://www.oracle.com/us/corporate/Acquisitions/secerno/index.html) which is an APIDS for SQL.

Hybrid Intrusion Detection Systems

Different types of Intrusion Detection Systems can also be combined. Combined systems arecalled Hybrid Intrusion Detection Systems. To completing this overview it must be mentioned,that IDSs can also be system-specific. This means they can use custom tools and Honeypotsfor getting a better efficiency. [Sca10]

1.3.3 Database Types of Intrusion Detection Systems

The Database Types of Intrusion Detection Systems are focused on two types of detectiontechniques. One is the Statistical Anomaly-based IDS Type and the other is the Signature-Based IDS.

Statistical Anomaly-Based IDS

Anomaly-based IDSs detect incidents, which show atypical behavior profiles or violate thresh-olds based on statistical analysis. Examples for this are possible masquerade attacks, whichare detected in this way or penetrations of the security control system. Another possible sce-nario is leakage or denial of service attacks, which are detected by atypical use of systemresources. Other problems include malicious use, violations of security constraints, or use ofspecial privileges.[Kiz46]Therefore, a statistical anomaly-based IDSs determines normal network activity. It recordswhat sort of bandwidth is generally used, what kind of protocols are used, which ports anddevices generally connect to each other- and alert the administrator or user when traffic is de-tected which is anomalous (not normal).[nM08] This could include to compare certain trafficindicator value against a threshold, based on their historically determined standard deviation.The SA-B IDS works with an Network History Database like shown in Fig. 1.3. This databasecontains information about previous behavior and events. The System has to consider three

Basics 14

main datasets: Statistical information based on historical data, user set thresholds and con-straints and finally the data of the current time window which is watched.

Figure 1.3: Example for Statistical Anomaly-based IDS

Signature-Based IDS

A signature based IDS monitors packets in the network and compares with preconfiguredand predetermined attack patterns known as signatures. When a new attack is recognizedexperts or programs have to identify typical patterns in such attacks, which can be made into asignature. Since this process takes time, there will be a lag between the new threat discoveredand signature being applied in IDS for detecting the threat. During this lag time your IDS willbe unable to identify the threat.[nM08]To reduce further lag, security software using such signatures should be updated as frequentlyas feasible. You can see an S-B IDS with an implemented Attack Signature Database inFig. 1.4.

Figure 1.4: Example for Signature-Based IDS

1.3.4 Response of IDSs

A short explanation should also be given for Passive and / or (Re)-Active Systems here. Ina Passive System the IDS sensor detects a potential security breach, logs the information andsignals, give an alert on the console and/or to the owner. See also Fig. 1.5 A (Re)-Active Sys-tem is also known and used as an Intrusion Prevention System (IPS). The mode of operation

Basics 15

of this System is to auto-respond to the suspicious activity by resetting the connection or byreprogramming the firewall. With the last Option the firewall has to block network traffic fromthe suspected malicious source. The term Intrusion Prevention Systems (IDPSs) is commonlyused, where this can happen automatically or at the command of an operator; So this systemsdo both they “detect”(e.g. alert) and “prevent”. [Sca10] See details for that kind of Systems inthe next Section.

Figure 1.5: Example for Passive and / or (Re)-Active Systems

1.4 Intrusion Prevention Systems

Intrusion Prevention Systems (IPSs) also known as Intrusion Detection and Prevention Sys-tems (IDPSs), are network security applications, that monitor and change network and systemactivities. The main functions of IPSs are, as explained before in the previous section, toidentify malicious activity, log information about it, attempt to block or stop and report thatactivity. [Sca10] Since they are not in the focus of this report, it is necessary to note here, thatthey are important parts of network security and strongly related to intrusion detection.

IPSs can be considered extensions of IDSs. The main differences that should be figured outbetween them are, that IDPs are placed in-line and are able to actively prevent or block in-trusions that are detected. [New09][Mat09] To be a little bit more precise it can be declared,that IPSs can take such actions as sending an alarm, dropping the malicious packets, resettingthe connection or blocking the traffic from the offending IP address. [Boy10] This might alsoinclude other actions like changing or reconfiguring firewall rules.Additional tasks of an IPS are correcting “Cyclic Redundancy Check (CRC) errors, unfrag-ment packet streams, prevent TCP sequencing issues, and clean up unwanted transport andnetwork layer options.” [Sca10] [Kra07] For that they are using several response techniques,which involve the IDPS stopping the attack itself.

1.4.1 Classifications of IDPSs

Intrusion Prevention Systems can be classified into four different types like shown in 1.1:[Sca10][Vac10]

Basics 16

Table 1.1: Classifications of IDPSsName ExplanationNetwork-based IntrusionPrevention (NIPS):

This kind of IDPS monitors the entire network for suspi-cious traffic by analyzing protocol activity.

Wireless intrusion pre-vention systems (WIPS):

WIPS monitors a wireless network for suspicious traffic byanalyzing wireless networking protocols.

Network behavior analy-sis (NBA):

That analysis Based IDPS examines network traffic toidentify threats that generate unusual traffic flows, such asdistributed denial of service(DDoS) attacks, certain formsof malware, and policy violations.

Host-based intrusion pre-vention (HIPS):

Is an installed software package which monitors a singlehost for suspicious activity by analyzing events occurringwithin that host.

1.5 Honeypots

Since this Case Study is focused on Intrusion Detection with different network configurationsHoneypots have to be considered, too.

Honeypots can be seen and used for both security tasks, Intrusion Detection and Prevention.However they do not fit very well into the definitions stated above, as they employ completelydifferent approaches.

Simply put, Honeypots are systems that simulate possible targets for an attacker. This meansif an attacker is focused on such a Honeypot, the real System is less in danger of being at-tacked. At the same time, observing traffic at a Honeypot can be used to detect maliciousactivities. Because no legitimate traffic should try to communicate with addresses related tothe Honeypots, any traffic that can be observed is suspicious.

1.5.1 Definition and further Details of Honeypots

Definition of Honeypots:

“In computer terminology, a Honeypot is a trap set to detect, deflect, or in some mannercounteract attempts at unauthorized use of information systems. Generally it consists of acomputer, data or a network site that appears to be part of a network, but is actually isolatedand monitored, and which seems to contain information or a resource of value to attackers.”[Wik12d]

further Details of Honeypots

Honeypots are frameworks, software or systems, which are specifically designed for intrusiondetection and prevention. They can even be used to determine the method of attack and tofollow new types of attack techniques. There is a number of criteria to classify different types

Basics 17

of Honeypots.

First they can be classified by their level of interaction; High interaction Honeypots simulatewhole operating systems while low interaction Honeypots only simulate certain services. An-other distinction can be done based on their deployment; Production Honeypots are easy touse, capture only the most important information and are used to directly harden security ofnetworks. Research Honeypots on the other hand try to capture a lot more information for thepurpose of investigating malicious activities and new attack approaches.

The biggest advantage of Honeypots is the ability to recognize a systems vulnerabilities, thusenabling the administration of the system to repair without loss of data or other damage. An-other important advantage is the option to determine, follow or even ban an IP address, whichtried to attack or hack a system.These advantages do not come without a prize. The number of simulated Honeypots increasesthe computational burden for the host machine and also the required network bandwidth. Theycan create significant costs in acquisition and maintenance, beside the cost for the softwareitself. There is significantly more to tell about Honeypots, and in the way they can be used forintrusion detection, prevention or for the analysis of malware. However we do not intend tofocus our case study on them, so we recommend to get more information from [Wik12d]. Formore details see the book from Joshi and Sadana. [JS11]

Basics 18

1.6 Intrusion Detection Software

On the free market you can find a great number of commercial IDSs and free Software, whichare listed and shortly explained in the following table 1.2. For further informations see also[Wik11b].

Table 1.2: Commercial intrusion detection systems and free SoftwareName ExplanationSNORT SNORT is one of the free network IDS for Unix/Linux-,

Mac OS X and Windows systems. It can use several mod-ules for the evaluation of the data (ex. ACID) or be up-graded with modules for intrusion prevention (ex. SAM).

Samhain Samhain is a host-based system that runs on many plat-forms. Many Linux distributions already include ready-made packages of this software. By cryptographic signa-tures can distortions in the communication and configura-tion files be detected via network.

Prelude Prelude as a hybrid IDS integrates a variety of other pack-ages (SNORT, Samhain, etc.), its also used on Platformslike Linux, BSD, Solaris, OSX, x86, PowerPC and SPARCetc.

Project Hogwash It uses Layer two with No IP-Address and its easy to im-plement but difficult to hack

Xray IDS Xray is an Host IDS designed for Windows . It is the firstsystem that was developed specifically for Windows.[Dev]

suricata suricata is a hybrid IDS. It is capable bothof detection and prevention.(http://www.openinfosecfoundation.org/)

Bro IDS Bro is a NIDS for unix systems, using signature baseddetection and other methods.(http://www.bro-ids.org/)

1.6.1 Honeypot Software

This section lists some Honeypot softwares and where to get them. The systems mentionedhere should be all free of charge.

• Honeyd:“Honeyd is an open source computer program created by Niels Provos that allows a userto set up and run multiple virtual hosts on a computer network. These virtual hosts canbe configured to mimic several different types of servers, allowing the user to simulatean infinite number of computer network configurations. Honeyd is primarily used in thefield of computer security by professionals and hobbyists alike, and is included as partof Knoppix Security Tools Distribution.” [Wik12a]

Basics 19

• HoneyMonkey:“HoneyMonkey, short for Strider HoneyMonkey Exploit Detection System, is a Mi-crosoft Research honeypot. The implementation uses a network of computers to crawlthe World Wide Web searching for websites that use browser exploits to install malwareon the HoneyMonkey computer. A snapshot of the memory, executables and registryof the honeypot computer is recorded before crawling a site. After visiting the site, thestate of memory, executables, and registry is compared to the previous snapshot. Thechanges are analyzed to determine whether the visited site installed malware onto thehoneypot computer.HoneyMonkey is based on the honeypot concept, with the difference that it activelyseeks websites that try to exploit it. The term was coined by Microsoft Research in2005. With honeymonkeys it is possible to find open security holes that aren’t yet pub-licly known but are exploited by attackers.”[Wik12b]

• HEAT:“Honeypot and forEnsic Analysis Tool or HEAT in short is a Live CD based on KNOP-PIX S-T-D distro and Tiny Honeypot by George Bakos. This tool is primarily a hon-eypot for monitoring networks for unauthorized intrusions on information systems. Italso doubles up as a forensic tool to perform analysis on the captured data. This tool islicensed under GNU GPL.The tool is a complete environment for testing networks and using the results to performforensic analysis of the data. This environment provides a solid platform for develop-ment, and vulnerability research. The majority of the tool is composed of componentswritten in Shell code and Perl.”[Wik12c]

• HoneyBOT:“A honeypot is a device placed on a computer network specifically designed to cap-ture malicious network traffic. The logging capability of a honeypot is far greater thanany other network security tool and captures raw packet level data even including thekeystrokes and mistakes made by hackers. The captured information is highly valuableas it contains only malicious traffic with little to no false positives.Honeypots are becoming one of the leading security tools used to monitor the latesttricks and exploits of hackers by recording their every move so that the security com-munity can more quickly respond to new exploits.[Ato11]

• LaBrea:“LaBrea takes over unused IP addresses, and creates virtual servers that are attractive toworms, hackers, and other denizens of the Internet. The program answers connectionattempts in such a way that the machine at the other end gets "stuck", sometimes for avery long time.[ORS]

1.6.2 Further Defensive Tools

In the next list are further defensive Tools for IDSs shown, which all deal with the AddressResolution Protocol (ARP). This Attribute is especially important as we show during thisreport. This is due to the fact that they are frequently employed in many attacks. You can

Basics 20

find additional information in [Wik11a]. In table 1.3 are defensive tools for ARP preventionshown an shortly explained

Table 1.3: ARP Defensive ToolsName ExplanationArpON Portable handler daemon for securing ARP against spoof-

ing, cache poisoning or poison routing attacks in static, dy-namic and hybrid networks.

AntiARP Windows-based spoofing prevention in kernel.Anticap Kernel patch for Linux, prevents mapping being overwrit-

ten (no longer available).Antidote Linux daemon, monitors mappings, unusually large num-

ber of ARP packets.Arp Antidote Linux Kernel Patch, watches mappings, can define reac-

tions on detected events.Arpalert Predefined list of allowed MAC addresses, alert if MAC

that is not in list.ArpStar Linux module for kernel 2.6 and Linksys router, drops in-

valid packets that violate mapping, option to repoison orheal.

Arpwatch-/NG/Winarpwatch

Keep mappings of IP-MAC pairs, report changes via Sys-log, Email.

remarp Remote Arpwatch, SNMP-based monitoring, mappingchanges.

Colasoft Capsa Alert ARP storms, imbalance on ARP request/response.Prelude IDS ArpSpoof plugin, basic checks on addresses.SnoopNetCop monitors local ARP cache (no longer available).Snort Snort preprocessor Arpspoof, performs basic checks on ad-

dresses. Tested in this study, found not to work properly.XArp Advanced ARP spoofing detection, active probing and pas-

sive checks. Two user interfaces: normal view with prede-fined.Tested to work well in this study. security levels, proview with per-interface configuration of detection modulesand active validation. Windows and Linux, GUI-based.

Basics 21

1.7 Penetration Testing tools

An important task of this case study was to make penetration test on real systems. In thissection you can find a list of tools that can be used for penetration testing. In the followingchapters some tools of this list will be covered in more details, as they were used for this casestudy. It is recommended to use these tools with care. Not all of them are open source andthus might contain unwanted features or even malicious code. It has also be considered to usethem in restricted environments to avoid damaging any third parties.This is not a complete list, but rather a summary of some of the most frequently used toolsavailable. For detailed information please read the recommended links of each tool.

1. Metasploit - Extensive framework for penetration testing. Exensible through custommodules.http://www.metasploit.com/

2. Cain and Abel - Tool for password recovery that also includes sniffing and man-in-the-middle attackshttp://www.oxid.it/cain.html

3. dsniff - Includes sniffing and spoofing (ARP, IP, DNS) techniques and SSH/SSL man-in-the-middle attackshttp://monkey.org/~dugsong/dsniff/

4. ettercap - Tool for man-in-the-middle attacks and sniffing in different netork protocollshttp://ettercap.sourceforge.net/index.php

5. Yersinia - Networking tool to test weaknesses in protocolls like DHCP or STPhttp://www.yersinia.net/

6. scapy - Packet manipulation program, create packets of various protocoll typeshttp://www.secdev.org/projects/scapy/

7. sslsniff - Exploits vulnerabilities in SSL/TLS connections, includes ARP spoofinghttp://www.thoughtcrime.org/software/sslsniff/

8. sslstrip - Demonstrates SSL strippinghttp://www.thoughtcrime.org/software/sslstrip/

9. NMap - Tool for alot of different reconnaissance tasks like ARP sweeps or TCP scanshttp://nmap.org/

10. SuperScan - Another scanning toolhttp://en.wikipedia.org/wiki/Superscan

11. paros - Network scanning and MITM and other web related attackswww.parosproxy.org

Basics 22

1.8 Attack Approaches

This section tries to give an overview over existing vulnerabilities and attack approaches, alsosummarizing some of their main features and properties. While the basic ordering of thissection is based on the different network layers in the ISO OSI model, this is not always aclear distinction. Some of the attacks can not be clearly associated with a specific layer, eitherbecause of their nature, or because they are dependent on other attacks.

1.8.1 Layer 1 Based Vulnerabilities

Due to their rather physical character, Layer 1 based vulnerabilities are not of interest for thiscase study. For completeness they are listed here but not explained in any detail.

1. Loss of Power

2. Loss of Environmental Control

3. Physical Theft of Data and Hardware

4. Physical Damage or Destruction of Data And Hardware

5. Unauthorized changes to the functional environment(data connections,removable me-dia, adding/removing resources)

6. Disconnection of Physical Data Links

7. Undetectable Interception of Data

8. Keystroke and Other Input Logging

1.8.2 Layer 2 Based Attacks

ARP Poisoning

The Address Resolution Protocol handles the mapping of MAC and IP addresses in a network.Each device in a network will store this mapping in a cache, typically called the ARP table.ARP poisoning tries to infuse wrong information into that table. Packets sent by the manipu-lated machine will then not be sent to legitimate devices, but to an IP address specified by thefaked ARP information.

There are various ways in which a targets ARP cache can be poisoned [Mah99]. One possibil-ity is to send ARP messages to the targeted machine repeatedly. That is, a fake ARP responsewhich contains the manipulated IP address. For further details on this attack approach pleasealso read the following source [Man03].

ARP spoofing is often a basic first step in many attacks, for instance in SSL-Man-In-The-Middle or in session hijacking. Therefore, detection of this kind of attack is of major impor-tance. Due to this importance diffent kinds of ARP attacks are shown in the practical part ofthis case study.

Basics 23

Mac Spoofing

Sometimes MAC addresses are used to regulate network access. In this case an attacker mightavoid the regulation by spoofing a MAC address. This can also be used to take over anotheridentity already on the network.The difference to ARP poisoning is, that here not the mapping of IP addresses and MACaddresses on a target device is altered, but rather that the MAC address of ethernet frames sentby the attacking machines are altered. For example, if the attacker knows a valid MAC addressin the network, he can use that to gain access. While MAC addresses should usually be uniquefor each device, they can still be easily changed by software [Wik11e].

DHCP Exhaustion / Starvation

In DHCP exhaustion attacks, an attacker will ask for as many IP addresses as possible, so thatthe DHCP server will have none left for any legitimate request by other devices.

It is effectively a Denial of Service (DoS) attack, but can be used as a first stage for otherattacks. Since a certain device will not be able to enter the network anymore, it might then bepossible to mimic that device for further steps.[VP07] For detection possibilities please havea look at [OCo01], which describes solutions based on simple python scripts for a number oflayer 2 attacks.

Mac Flooding

MAC flooding is a rather simple attack on switched networks. The attacker simply spams thenetwork with messages, each containing different mac addresses. Switches will continue tosave each mac address in their CAM table, and at some point they might overflow. For olderswitches the resulting behavior is to go into broadcast mode, which means MAC flooding isperfect, if it is of interest to hear the whole network traffic on a switch.[VP07] [OCo01]

Rouge DHCP Server

A Rouge DHCP server would mean an unauthorized server, that tries to answer any DHCPrequests with manipulated information. This could be done to block devices by giving thefalse information, or to manipulate them into using wrong gateways or DNS servers.[VP07]

Spanning tree Attack

The spanning tree protocol (STP) is used for managing network topology. This is done bycomparing priorities and ID values of bridges in the network. Based on this information a rootbridge is chosen. Once a root bridge is found, a calculation leads to choosing the best pathsfor each device in the network leading to the root bridge, and eliminating any additional loops.

An attack on this protocol is called spanning tree attack, and could mean that an attackertries to send faked STP messages which have the purpose of making him the root bridge. Thiscan be tested with well known penetration testing tools like yersinia which include this typeof attack.[K.A11]

Basics 24

Hidden Node Attack (wireless)

This and the following two sections contain information about attacks based on wireless net-works. Due to the extend of our case study and the need for additional equipment, they werenot tested in our study. The hidden node attack employs Ready To Send RTS or Clear To SendCTS messages used in wireless communication to flood the network. Any network devicehearing them will refrain from doing any further communication, because it expects that thereis an unknown device (hidden node) that is sending at the moment. An implementation of thisattack is available with Metasploit, as demonstrated in [OCo01].

DEAUTH attack (wireless)

While authentification messages between clients and access points in wireless networks em-ploy some sort of security, deauthentification does not. Thus an attacker is able to deauthen-tificate a device from an access point by simply sending faked deauthentification frames to theaccess point. An implementation of this attack is available with Metasploit, as demonstratedin [OCo01].

Fake access point attack (wireless)

Faking access points can simply be done by setting up a system that will automatically tryto answer any kind of AP probes. A possible implementation could be found here http://www.blackalchemy.to/project/fakeap/ It is also mentioned in [OCo01] thatthere are modules in Metasploit which employ similar methods.

1.8.3 Layer 3 Based Attacks

IP Spoofing

IP spoofing means to send messages with fake IP addresses. This can for instance be usedto avoid filtering techniques, if for some attack a large number of messages have to be sent.If each message has a different, spoofed IP a defensive system will have more difficulties todetect or prevent them [Wik11d]. More elaborate attacks might use IP spoofing to actuallypretend as another device on the network, thus trying to infuse manipulated packages in acommunication.

IP Scan/Sweep: Ping(ICMP)

Scanning for services in a network can be important to locate possible vulnerabilities whichcould be exploited. A simple ICMP sweep might be part of such a scan. This implies sendinga number of ICMP messages to different hosts, and analyzing the response.[K.A01] Tools likenmap employ this automatically to map the network. ICMP messages can also be used togather information on the routing in the network (traceroute) or the filtering rules of firewalls,see also: http://packetstormsecurity.org/UNIX/audit/firewalk/.

Basics 25

Routing (RIP) Attacks

The routing information protocol RIP handles routing information of a network. That includesinformation about which path might be shortest for a certain communication. An attacker cansend faked RIP packages to pretend as fastest route. This attack might require other techniqueslike IP spoofing to actually infuse the manipulated RIP messages into a target [Nat03].

ICMP (DOS)

To DOS a target system, the ICMP messages for time exceeded or destination unreachablecould be employed. This will break any connection between affected hosts. Another approachmight be a so called "smurf" attack which involves sending an echo request to a network.Any machine in a network could reply to it. This would multiply the traffic by the number ofmachines on the network, thus flooding it with ICMP messages. Of course these attacks arerather old and well known. Migitation is thus rather trivial, blocking certain ICMP requestsand broadcasts is a standard technique [VP07].

1.8.4 Layer 4 Based Attacks

UDP scans

As mentioned before, knowing the targeted network is important. It is often the first step forany kind of attack, unless for some reason knowledge of the target network is already existing.UDP scans send messages to different ports, and discard them if an ICMP message is sendback indicating that the port is not reachable. This might not work if the original messageis simply dropped by a firewall. More elaborate UDP scans thus employ specific applicationlayer messages, to identify open ports more clearly [Wik11f].

TCP scans

TCP scanning is usually easier than UDP scanning. Either it sweeps all ports and tries to do athree-way-handshake to validate open ports, or a SYN packet is sent so that any open port willrespond with SYN-ACK acknowledge message [Wik11f].

TCP “SYN” attack

A simple DoS attack can be to send synchronization requests to a server, but to ignore ac-knowledging the response. This can make the server repeat its response, thus creating a lot ofresponse messages with just one request. Repeating this with different spoofed IP addressescould cause a denial of service.

SSL Man-in-the-Middle Attacks

It is rather hard to tell for some attacks, what layer they belong to exactly, as many might beinvolved during the whole process. MITM are a typical case for this. SSL man in the middleattacks aim at compromising SSL sessions, meaning that the attacker tries to see the encryptedmessages in plain text.

Basics 26

In the example described by [Bur02] this implies that first ARP poisoning is done (of coursereconnaissance has to come even earlier, but it is assumed here that the needed knowledge isalready there). This is done, so that the attacker can assume the role of the gateway. After-wards DNS spoofing is to be done, so that the attacker does not simply act as fake gateway,but will also act as the desired Web server towards the victim.If all this is done, later the attacker will handle one encryption session with the real server, anda separate session with the victim. Thus any message sent or received will end up in plain textfor the attacker.As described by the aforementioned document this complete process could be done with thedsniff tool. The document also refers to other approaches to SSL MITIM attacks, those how-ever depending on various weaknesses in specific browsers/clients rather than the SSL conceptin general.

Land Attack

A Land Attack is a rather old attack which should be no issue on any recent systems. It dependson the sending of packages (for instance TCP SYN) that have the same source and destinationaddress. This used to crash some systems affected by weak implementations of TCP/IP. It isnot only rather old, but could also be easily filtered by security systems [Owe05].

TCP Session Hijacking

TCP hijacking can exploit a “desynchronized state” in TCP communication. When two hostsare desynchronized enough, they will discard (ignore) packets from each other. An attackercan then inject forged packets with the correct sequence numbers (and potentially modify oradd commands to the communication). For this attack finding out the correct sequence numberis one of the most important steps. In most cases it will be necessary to use spoofed IP andMAC addresses to perform session hijacking.There are some tools that supposedly can be used to do session hijacking:

1. hunt:details can be found at http://packetstormsecurity.org/sniffers/hunt/

2. juggernaut:details can be found at http://www.phrack.com/issues.html?issue=50&id=6#article

3. paros:details can be found at http://www.parosproxy.org/download.shtml

1.8.5 Layer 5++ Based Attacks

There are also a number of attacks known on Layer 5 and higher, although they are often veryspecific to certain applications. While they might be interesting from a general viewpoint,they are mostly not that interesting if the focus are typical industrial networks unless they aredesigned specificly for this area. Similar to some attacks already mentioned, they also largelydepent on more simple attacks on lower levels as staging points.

Scenarios 27

2 Testing Environment

2.1 Scenario

To perform penetration testing and intrusion detection, a rather simple test scenario is used inthis case study . Due to the fact of using limited resources, virtual machines in a single virtualsubnet were realized as test scenario.The main aim is to set up three machines:

• The first machine is configured as a potential target for intrusion attacks.

• The second machine is the IDS of the network

• For the third machine, which is the potential Intruder, different test cases for intrusionattempts are set up.

The details of this setup are explained in the following section.It has to be noted, that it is not the main point of this report to demonstrate actually successfulattacks with real impact. The aim is rather to demonstrate or simulate attacks, to analyze howand with what software a certain attack might be detectable.

2.2 Virtual Machines setup

The testing environment is set up with Virtual Box VB, using a virtual network that includesthe Host (called Host-only network in VB). It was first considered to use VMware virtualmachines, however the free version does not include the necessary tools to use simulatednetworking.The first machine ids1 is set up as the intrusion detection device in windows. SNORT wasinstalled with the most recent default rule set, too. The ids1 is furthermore used to run xARPand Wireshark was also installed to analyze network traffic during penetration tests.The second machine ids2 was set up with Windows, to try different intrusion attempts. Forthis the first intrusion software used was Metasploit, a well known software for penetrationtesting. It proved to be problematic on Windows, and was the reason to switch to Ubuntu. Themachine ids2 was kept as a possible target for attacks.

The Ubuntu machine ids3 was installed to run penetration testing tools like Metasploit ordsniff.Since SNORT also proved to be unreliable, we set up another machine ids4 for detection. Thismachine uses Ubuntu and was set up to run suricata.Additionally we tested SSD Snorby Security Distribution ids5, which is provided as a pre-installed Linux image. It includes scripts for configuring and updating the included SNORT

Scenarios 28

version, as well as a web interface that can be used to supervise detection results from othermachines in the network.This 5 machines were all set up as shown in Table 2.1 and also can be seen in Figure 2.1. Thetable also lists devices that are part of the VB host system. IP addresses were chosen in themachines operating systems, while the MAC addresses can be configured in the VB-manager.Besides the MAC addresses the VB-manager has to be used to set a virtual network interfacefor each machine to Host-only. These adjustments can all be done in the Network tab of eachmachines settings.

Network Overview

Table 2.1: Network Overview; IP addresses might change for certain use cases (e.g., whenDHCP is used)

Name OS IP MacVBhost Win7 192.168.56.1 08:00:27:00:b8:adVB DHCP server - 192.168.56.100 08:00:27:d2:f2:7dids1 - detection WinXP 192.168.56.101 08:00:27:6e:60:9eids2 - target WinXP 192.168.56.102 08:00:27:70:af:a3ids3 - attacker Ubuntu 192.168.56.103 08:00:27:be:82:0cids4 - detection Ubuntu 192.168.56.104 08:00:27:d5:32:35ids5 - detection SSD linux image dynamic 08:00:27:6b:ec:ec

Figure 2.1 shows an overview of all systems in the network with their installed software. Theinstallation of used software will be described in the following section.

Scenarios 29

Virtu

al B

ox „

Ho

st O

nly

“ E

the

rne

t

Virtu

al B

ox

DH

CP

Se

rve

r

VM

: id

s4

- d

ete

ctio

n

VM

: id

s1

- d

ete

ctio

n

VM

: id

s3

atta

cke

r

VM

: id

s2

– a

tta

cke

r/ta

rge

t

VM

: id

s5

- d

ete

ctio

n

Virtu

al B

ox H

ost M

ach

ine

Win

do

ws 7

Win

do

ws X

PW

ind

ow

s X

P

Tu

rnke

y lin

ux

Sn

ort

Sn

ort

Su

rica

ta

dsn

iff

Ho

ne

yd

Wire

sh

ark

ma

cch

an

ge

r

Figu

re2.

1:N

etw

ork

and

soft

war

eov

ervi

ewof

test

ing

envi

ronm

ent

Scenarios 30

2.3 Installation of used Software

2.3.1 SNORT on windows

SNORT Installation

SNORT first was installed on a windows machine, namely on ids1. For windows systems thereis an installer available on http://www.snort.org/snort-downloads. In this casestudy Snort_2_9_2_Installer.exe was used. To install, simply follow the instructions in theinstaller. SNORT is shipped with some default rules and a predefined configuration file.

Afterwards it is needed to adapt the default configuration file. This file is located in thesnort/etc directory, and is called snort.conf. The main things to be changed here are paths,which might not fit to the actual setup and one parameter: ipvar. Depending on the fact if IPv4or IPv6 is used, this parameter has either to be var or ipvar. The default config file can befound in C:/Snort/snort.conf (assuming SNORT was installed to C:/Snort).

SNORT Rules

Its a fact that SNORT needs rules to work. Of course one can always write new rules, whichhowever is complicated. Especially if a security system is set up, it might not be desirableto write all rules anew. The effort of writing new rules is probably only justified in specialcases were specific threats are to be detected. More generally known problems should thus becovered by the standard rule sets.While SNORT does ship with some default rules, it is recommended to download the mostup-to-date rules from the following website: http://www.snort.org/snort-rules.Unlike the main SNORT download, those rules require free registration. Registered users getnew rules 30 days after release, to get them earlier one would have to subscribe.The downloaded rules files can be extracted to the SNORT installation directory, and will alsocontain a new snort.conf file. That should be replaced or edited, as mentioned above.

A Simple Test

After installing SNORT and its rules it is recommended to test, if it is working properly andgenerating alerts.For a first simple test, one could run SNORT just as a sniffer, logging packages in the sameway that wireshark does. The other possibility is to actually test the detection capabilities.With the following command SNORT can be started in IDS mode, with active logging.

c : \ S n o r t \ b i n \ s n o r t −d −h 1 9 2 . 1 6 8 . 5 6 . 0 / 2 4 − l c : \ S n o r t \ l o g −c c : \ Snor t \ e t c \ s n o r t . con f

The IP address specifies the network to be watched by SNORT. Both the used configurationfile and the logging directory have to be specified. One important point is, that logging everypackage can create a large amount of DATA. If all packages are logged, and there are largefiles sent and received in the network, this might cause undesirable large log files. You shouldbe aware of this when starting logging.Now that SNORT is running, a simple test can be done to verify its detection capability. For

Scenarios 31

example you can send a ping to the machine, where SNORT is installed on. To do so open thewindows command line tool (cmd.exe), and enter the following:

p ing 1 9 2 . 1 6 8 . 5 6 . 1 0 1

This will produce a low priority alert, as a ping is not normal behavior but rather used fornetwork debugging. In fact pings (ICMP) will by default be blocked by the windows firewall.In case the ping times out, this will have to be changed first (deactivate firewall or removeblock for ICMP). If everything works, the result of the alert will show up in snort/log/alert.idswhich could be opened with a text editor:

[ * * ] [ 1 : 3 8 2 : 7 ] ICMP PING Windows [ * * ][ * * ] [ 1 : 3 8 2 : 7 ] ICMP PING Windows [ * * ][ C l a s s i f i c a t i o n : Misc a c t i v i t y ] [ P r i o r i t y : 3 ]11 /08 −15 :41 :09 .406929 1 9 2 . 1 6 8 . 5 6 . 1 0 2 −> 1 9 2 . 1 6 8 . 5 6 . 1 0 1ICMP TTL:128 TOS: 0 x0 ID :178 IpLen : 2 0 DgmLen : 6 0Type : 8 Code : 0 ID :512 Seq :2560 ECHO[ Xref => h t t p : / / www. w h i t e h a t s . com / i n f o / IDS169 ]

There will be a number of alerts, one for each ping and response. As can be seen, the pingis logged with all important information, and the alert is given a priority of 3. By default apriority of 3 is the lowest priority, while 1 is the highest.

2.3.2 How to install suricata

This is a short How-To about installing suricata, describing the steps taken in this case study,to install and configure it on the ids4 Ubuntu machine. For further information please have alook at the installation guide in the quick start guide on:https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Quick_Start_Guide.The first step is installing suricata itself with the following command.

sudo ap t−g e t i n s t a l l s u r i c a t a

The next step is to install some dependencies.

sudo ap t−g e t −y i n s t a l l l i b p c r e 3 l i b p c r e 3 −dbg l i b p c r e 3 −dev \b u i l d−e s s e n t i a l a u t o c o n f automake l i b t o o l l i b p c a p −dev l i b n e t 1 −dev \l i b y a m l −0−2 l i b y a m l−dev z l i b 1 g z l i b 1 g−dev l i b c a p −ng−dev l i b c a p −ng0 \make

Afterwards the network configuration should be checked to find out the interface name in theterminal.

i f c o n f i g

Now suricata can be started with the found interface name, here “eth0”.

sudo s u r i c a t a −c / e t c / s u r i c a t a / s u r i c a t a −d e b i a n . yaml − i e t h 0

The running application can be stopped as in all Linux based programs with “ctrl+c” For anoverview on the current status you can open a new terminal and run the following lines.

t a i l h t t p . l o gt a i l −n 33 s t a t s . l o gt a i l −f h t t p . l o g

Scenarios 32

To manage the rule set, Oinkmaster is needed.

sudo ap t−g e t i n s t a l l o i n k m a s t e r

The next step is to set the url in the oinkmaster.conf.

sudo nano / e t c / o i n k m a s t e r . con f

In the editor use the following url: http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz Afterwards the file can be saved and closed andnext the directory for the rules should be created.

sudo mkdir / e t c / s u r i c a t a / r u l e s

The configuration file of oinkmaster can be used to load current rules to the new directory.

cd / e t csudo o i n k m a s t e r −C / e t c / o i n k m a s t e r . con f −o / e t c / s u r i c a t a / r u l e s

In the directory a classification.config and a reference.config can be found. The paths of bothhave to be added in the suricata.yaml file. It can usually be found in the following folder.

sudo nano / e t c / s u r i c a t a / s u r i c a t a . yaml

Suricata is now prepared to run.

As an additional step, to convert log files with unified2 format, install barnyard2 and its de-pendencies like shown here.

sudo ap t−g e t i n s t a l l mysql−c l i e n t l i b m y s q l c l i e n t −dev

sudo wget −O barnya rd2 −1 .9 . t a r . gz h t t p : / / www. s e c u r i x l i v e . com /download / b a r n y a r d 2 / ba rnya rd2 −1 .9 . t a r . gz

sudo t a r zxv f ba rnya rd2 −1 .9 . t a r . gz

cd ba rnya rd2 −1.9

sudo . / c o n f i g u r e −−with−mysql

make

sudo make i n s t a l l

sudo cp e t c / b a r n y a r d 2 . con f / e t c / s u r i c a t a

sudo mkdir / v a r / l o g / b a r n y a r d 2

Now view log files with barnyard2 batch mode (alert file name is an example).

sudo b a r n y a r d 2 −c / e t c / s u r i c a t a / b a r n y a r d 2 . con f −o u n i f i e d 2 .a l e r t .1323699996

Scenarios 33

2.3.3 How to install Snorby Security Distribution

The Snorby Security Distribution SSD is another version of SNORT, which is a ready-to-usedistribution and was also tested in this Case study. Snorby is a web front-end for SNORT. It ispre-installed on a Linux image, which can be installed as a whole on any machine. In our caseit was installed as virtual machine on ids5.To do so the following steps have to be performed.

1. Download SSD: http://bailey.st/blog/snorby-spsa/

2. Use the .iso image to install a new virtual machine

3. Follow installation instructions

4. Configure ip adress to match network settings (for instance with IP set to dynamic)

5. Keep snorby machine running

6. On another machine in network: access https://ipadress:8080 with User "Snorby" andpassword "admin" here you can see events, etc

7. To change settings or rules of the snorby image go to the machine, quit the turnkeymenue to go to linux command line

8. In command line type "vi /etc/snort/snort.conf" to enter configuration file

9. Press i to go into insert mode

10. Change configuration (for instance uncomment rule sets that are supposed to be used)

11. Use escape to cancle insert

12. type :wq to leave file and save

13. Now restart snort with: /etc/init.d/snort stop - /etc/init.d/snort start

This is an easy to use installation, because it can be supervised with the web front-end and ev-ery dependency is pre-installed on the image. This includes scripts for restarting and updatingof rule sets.

2.3.4 Installing Metasploit Framework on Windows

Metasploit Framework is an open Framework for penetration testing. It includes a lot of mod-ules and is extensible with custom modules, that can be used for testing and demonstratingvulnerabilities in networks. While there is a distribution of Metasploit for Windows available,we did refrain from using it after testing it shortly. Installation is quite easy, but it seems thatgetting it to run is not. The dependency on the programming language Ruby makes it hard tohandle. We recommend to use a Linux version, but if Windows seems unavoidable we refer tothe official documentation on:(https://community.rapid7.com/docs/DOC-1298).

Scenarios 34

2.3.5 Installing Metasploit Framework on Ubuntu

To install Metasploit on ids3 the most recent installer for Linux was downloaded from [Met11].Since the installer is graphical, it will need graphical sudo to run it as root.

gksudo . / m e t a s p l o i t − l a t e s t −l i n u x− i n s t a l l e r . run

Everything else can be done easily by following the instruction of the installer. Before runningthe Software the following command can be used to update the framework.

sudo msfupda t e

To run the Metasploit console use the following command.

sudo m s f c o n s o l e

2.3.6 Installing dsniff (Ubuntu)

The dsniff program, which includes a number of penetration testing, sniffing and networkingtools is installed on Ubuntu with the following command lines.

sudo ap t−g e t i n s t a l l d s n i f f

For this case study it was installed on ids3.

2.3.7 Install Honeyd

As an example for a Honeypot system, honeyd was used in this case study. Honeyd wasinstalled from the terminal of the Ubuntu ids4 machine.

sudo ap t−g e t i n s t a l l honeydsudo ap t−g e t i n s t a l l f a r p d

The additional installation of farpd is required to route traffic of unclaimed IP addresses tohoneyd.

2.3.8 Install macchanger

Macchanger is a tool to change the mac address of a Linux machine. It was installed on ids3,using the terminal.

sudo ap t−g e t i n s t a l l macchanger macchanger−g t k

The second (macchanger-gtk) is not strictly necessary, but can be used to change mac ad-dresses by using a graphical user interface.

2.3.9 Install xARP

xARP is a tool to watch (free version) and protect from (commercial version) any attemptsto compromise networks with attacks based on weaknesses in ARP. The free version can bedownloaded from [chr11] , both for Linux (Ubuntu) or Windows. In this case study theWindows version was used and installed on ids1. To do so the windows 32bit installer (Version2.2.2) was downloaded. Besides following the installers instructions, no further steps wereperformed.

Test Cases 35

3 Test Cases

In the first chapter the attack approaches of interest for this case study were listed, sorted bytheir associated ISO OSI model layer. For next we focus on detecting attacks that might be ofinterest in a industrial networking environment, attacks from Layer two to four are chosen.They are based on rather well known vulnerabilities. The first reason why such well knownattacks were chosen, was that they are well documented and thus can be reproduced moreeasily. The second and more crucial reason is, that there will never be a situation, where anyunknown attack can be tested. Penetration testing can only be done with known attacks. Thebest thing what could be done for penetration testing would be to think ahead and trying tofind new weaknesses in used protocols. This however can be hard, and might not yield relevantresults. Therefore, most penetration testing can only be done with known attacks. This leads toa need of continuous inquiry for new vulnerabilities as published by researchers and technicalexperts.This case study is not focused on finding any outstanding new vulnerabilities. It rather triesto show for a number of test cases, how known attacks can be tested, analyzed and used toimprove the detection capabilities of an IDS.The following test cases are built up as follows. First of the specific attack is outlined, andthe basic steps done to perform it are explained. Secondly it is described how this kind ofintrusion attack might or might not be detected.Based on the test environment described earlier, it is then attempted to practically perform anddetect the intrusions. If detection with available software fails, it is attempted to figure out ifother software might do better or if other measures are applicable.

3.1 ARP Poisoning(Layer 2)

The ARP table of a network device stores the MAC addresses and their associated IP addresses.To mislead or manipulate communication, ARP poisoning tries to change the entries in thattable by sending faked ARP messages.To simulate this attack, 3 of our virtual machines were used: ids1 (Windows detection) ids2(Windows target) and ids3 (Ubuntu attacker).

3.1.1 Arp Test

The ARP attack that we test here is performed with Metasploit, but can also be done withnumerous different tools mentioned in this report, for instance dsniff. For doing so follow theinstructions to install Metasploit(previous chapter) and after completion start Metasploit.

sudo m s f c o n s o l e

In the console, the following commands will start an ARP poisoning attack:

Test Cases 36

use a u x i l i a r y / s p o o f / a r p / a r p _ p o i s o n i n gs e t DHOSTS 1 9 2 . 1 6 8 . 5 6 . 1 0 1s e t SHOSTS 1 9 2 . 1 6 8 . 5 6 . 1 0 2run

This will prompt Metasploit to do an ongoing ARP poisoning attack.In this case, our target was 192.168.56.101 (ids1), where SNORT is running. So the ARP tableof ids1 will be poisoned, to intercept communication with ids2. After this attack is started onthe ids3 machine, lets see how this affects our target. To actually see the poisoning one canfirst look at the ARP tables current input.

c : \ S n o r t \ b in > a r p −a

S c h n i t t s t e l l e : 1 9 2 . 1 6 8 . 5 6 . 1 0 1 −−− 0x2I n t e r n e t a d r e s s e P h y s i k a l . Adres se Typ1 9 2 . 1 6 8 . 5 6 . 1 0 3 08−00−27−be−82−0c dynamisch

As can be seen, the ARP table currently only contains the MAC address and IP address of theattacking machine, since there was no other communication yet. However what happens ifanother machine in the network is pinged:

c : \ S n o r t \ b in > p ing 1 9 2 . 1 6 8 . 5 6 . 1 0 2

Ping wird a u s g e f ü h r t f ü r 1 9 2 . 1 6 8 . 5 6 . 1 0 2 mi t 32 Bytes Date

Antwor t von 1 9 2 . 1 6 8 . 5 6 . 1 0 2 : By tes =32 Z e i t =2ms TTL=128Z e i t ü b e r s c h r e i t u n g d e r Anforde rung .Z e i t ü b e r s c h r e i t u n g d e r Anforde rung .Z e i t ü b e r s c h r e i t u n g d e r Anforde rung .

Ping−S t a t i s t i k f ü r 1 9 2 . 1 6 8 . 5 6 . 1 0 2 :P a k e t e : Gesende t = 4 , Empfangen = 1 , V e r l o r e n = 3 (75

Ca . Z e i t a n g a b e n i n M i l l i s e k . :Minimum = 2ms , Maximum = 2ms , M i t t e l w e r t = 2ms

As can be seen, only the first ping seems to go through, but the others fail to get a response.The reason for this is the successful poisoning done by the Metasploit module. This becomesobvious, if the ARP table is checked again.

c : \ S n o r t \ b in > a r p −A

S c h n i t t s t e l l e : 1 9 2 . 1 6 8 . 5 6 . 1 0 1 −−− 0x2I n t e r n e t a d r e s s e P h y s i k a l . Adres se Typ1 9 2 . 1 6 8 . 5 6 . 1 0 2 08−00−27−be−82−0c dynamisch1 9 2 . 1 6 8 . 5 6 . 1 0 3 08−00−27−be−82−0c dynamisch

As can be seen above, both IP addresses are now associated to the one single MAC addressused for the attack. At this point, also a ping from the unaffected machine will not be answeredany more.

c : \ > p ing 1 9 2 . 1 6 8 . 5 6 . 1 0 1

Ping wird a u s g e f ü h r t f ü r 1 9 2 . 1 6 8 . 5 6 . 1 0 1 mi t 32 Bytes Daten :

Test Cases 37

Z e i t ü b e r s c h r e i t u n g d e r Anforde rung .Z e i t ü b e r s c h r e i t u n g d e r Anforde rung .Z e i t ü b e r s c h r e i t u n g d e r Anforde rung .Z e i t ü b e r s c h r e i t u n g d e r Anforde rung .

Ping−S t a t i s t i k f ü r 1 9 2 . 1 6 8 . 5 6 . 1 0 1 :P a k e t e : Gesende t = 4 , Empfangen = 0 , V e r l o r e n = 4 (100\% V e r l u s t )

Still, the ARP table of the second machine is not affected, it just can not receive the pingresponse, because every response will be sent to ids3 instead.

c : \ > a r p −a

S c h n i t t s t e l l e : 1 9 2 . 1 6 8 . 5 6 . 1 0 2 −−− 0x2I n t e r n e t a d r e s s e P h y s i k a l . Adres se Typ1 9 2 . 1 6 8 . 5 6 . 1 0 1 08−00−27−6e−60−9e dynamisch

In fact, after waiting a while the ARP tables will be cleared again, which will always resultinto a first ping going through, before the ARP poisoning takes over again. To get a betterunderstanding, have a look at Fig.3.1, which shows a Wireshark recording done on the SNORTmachine.

Figure 3.1: Wireshark recording for ARP attack

It can be concluded that what the attack simply does is spamming a response to an ARPrequest. This will not affect the ARP table as long as it is not asked for. Unasked ARPresponses are ignored. But when asking for the MAC address associated to the ping, first anARP request is send. Since the faked ARP message is sent with a fixed frequency, the ids2machine manages to send its ARP response and also the response to the ping, before the nextfake message arrives. Therefore, the first ping goes through. The fake message will thenoverwrite the entry in the table, so any pings after the first will not reach the real destination.A much faster timing for the faked ARP messages would probably even intercept the veryfirst ping. On the other hand it would also be more noisy and more prone to raise suspicion.Alternatively, a more elaborated algorithm could watch for ARP requests manually and only

Test Cases 38

send the faked messages when asked for. Still it would be difficult to beat the response timeof the real destination.Because of these issues it might be a security solution to limit the considered ARP responsesto one. This still might not be save, especially if the attacker is lucky enough to get a fakedARP response to the victim before the real response reaches the attacked victim. Regardlessof this, for better security it is reasonable to watch for ARP poisoning or spoofing with IDStools. The problem is that SNORT did not raise any alerts while the above attack was takingplace. So the conclusion of this is that the ARP attack went on unnoticed. In an attempt to fixthis, the following lines were added to the snort.conf, as suggested by the manual.

p r e p r o c e s s o r a r p s p o o f : −u n i c a s tp r e p r o c e s s o r a r p s p o o f _ d e t e c t _ h o s t : 1 9 2 . 1 6 8 . 5 6 . 1 0 2 0 8 : 0 0 : 2 7 : 7 0 : a f : a3p r e p r o c e s s o r a r p s p o o f _ d e t e c t _ h o s t : 1 9 2 . 1 6 8 . 5 6 . 1 0 1 0 8 : 0 0 : 2 7 : 6 e : 6 0 : 9 e

Still no alerts were generated. While some successes in using SNORT against ARP poisoningare reported on the web, there seem to be a lot of different problems concerning the SNORTarpspoof preprocessor. In fact the arpspoof preprocessor seems not to be working robust in itscurrent condition.So instead we searched for a more adequate program to detect these kind of ARP attacks.As often mentionend there is a number of detection tools available on the market. One verysimple to use tool for Windows and also here used tool is xARP. To get it working it had to beinstalled and started. (Hint: no additional configuration changes were done).

Figure 3.2: Screenshot of xARP during ARP poisoning on ids1

Test Cases 39

As can be seen in Fig. 3.2, the ARP poisoning attack was detected, as soon as it was started, bythis detection software and an alert was raised. xARP detects any kind of change to existingentries in the ARP table and can compare new entries to previous knowledge about MAC orIP address pairs in the network. It has to be noted that this should be done with care, sinceby default it will use whatever ARP information is visible on startup. If this information isalready compromised, an attack might not be detectable for xARP or for any other detectionsoftware, that does not use predefined MAC or IP lists.The Screenshot in Fig. 3.4 additionally verifies, that xARP can also detect attacks not directedto the machine, where xARP is running on. Here Metasploit was used to poison the ARP tableof ids2 and changing the ARP entry for the DHCP server, as shown in Fig. 3.3.

Figure 3.3: Screenshot in msfconsole for ARP poisoning

Figure 3.4: Screenshot of xARP during ARP poisoning on ids2

Test Cases 40

3.2 Mac Flooding

Switches store information, for example which MAC address is on which port in the CAMtable. If this CAM table overflows old switches will go into broadcast mode. This is interestingfor an attacker, since it will enable him to sniff the traffic on the switch.To overflow the CAM table, it is only necessary to spam the switch with as many differentMAC addresses as possible. The tool dsniff was used on the Ubuntu machine ids3 to do this.dsniff includes the macof tools, which performs MAC flooding. Until stopped it will sent outTCP packets, each with a different MAC and IP address. A Wireshark recording of this can beseen in Fig. 3.5 Thus the tool also employs a simple form of IP spoofing. Since macof doesnot expect an answer to its messages, the spoofed IP addresses are of no further interest. Ifdsniff is installed, MAC flooding can be started with the following command.

sudo macof

Figure 3.5: Screenshot of wireshark during macof MAC-flooding

Detection of this kind of attack should be possible by statistical methods, if the number andsize of TCP packets on the network is tracked. This kind of attack should usually create in avery short time a high number of very small packets. A very simple python script to do that ispresented in [OCo01].Also depending on how the attack is performed, the structure of the packets can be used todetect the attack. As already seen in the Wireshark recording, the packets are flagged to be

Test Cases 41

malformed.If suricata is run at the same time, it will create a high number of of alerts during the macofattack. Each alert mentions "BAD-TRAFFIC loopback traffic", with a priority of 2 (1 is max)this can be seen in Fig. 3.6.

Figure 3.6: Suricata alerts during MAC flooding

Finally, Honeypots might be a reasonable way to detect MAC flooding, too, if they monitorrandomly created IP addresses and not just a limited range.

3.3 DHCP Starvation (Layer 2)

DHCP exhaustion is a simple form of denial of service attack against a DHCP server. Byasking the server repeatedly for new IP addresses the attacker tries to exhaust the addressspace, so that new devices will get no dynamic IP addresses.For a first approach the DHCP exhaustion module for Metasploit by digininja [Dig11] wasconsidered, however that module could not be successfully loaded in the msf console. So,instead the simple shell script below was used to start the DHCP starvation attack.

1 # ! / b i n / bash2 w h i l e t r u e ; do3 # k i l l a l l r u n n i n g DHCP c l i e n t s − j u s t i n c a s e4 k i l l a l l d h c l i e n t5 rm −f / v a r / run / d h c l i e n t . p i d67 # b r i n g down t h e i n t e r f a c e8 i f c o n f i g e t h 0 down9

10 # change t h e MAC a d d r e s s o f t h e i n t e r f a c e and p r i n t t h e

Test Cases 42

11 new MAC a d d r e s s12 macchanger −a e t h 0 2>&1 | g r ep Faked1314 # b r i n g t h e i n t e r f a c e up15 i f c o n f i g e t h 0 up1617 # make a new DHCP l e a s e18 d h c l i e n t e t h 0 2>&1 | g r ep DHCPACK19 done

This shell script first kills any running DHCP client, then deactivates the network interfaces.Now the MAC address can be changed by using macchanger. Afterwards the script restarts thenetwork interface and asks for a dynamically distributed IP address. This is done in an endlessloop. Depending on the range of the DHCP servers address space, it will take some time to fillup the whole address space. When this happens, any new device that needs a dynamic IP, willget no response from the DHCP server. An attacker can exploit this and use his own rougeDHCP server to send false information to the affected device.We demonstrate this by first only using ids1 and ids3, where ids1 is used to capture the attackwith Wireshark and ids3 to start the attack. The target of the attack is the DHCP server, whichin this case is the virtual DHCP server provided by VirtualBox. The configuration for theDHCP server is shown in Fig. 3.7.

Figure 3.7: Virtual Box DHCP server settings for DHCP exhaustion demonstration

As can be seen the address space of the server was limited to 5 IP addresses, so that the attackworks faster. Once these settings are chosen, the virtual machines and the host machine shouldbe restarted for the changes to take effect. Elsewise the DHCP server will keep its old settings.Afterwards, the attack can be started on ids3 with the following command:

sudo . / s h e l l s c r i p t n a m e . sh

That attack can be recorded with Wireshark, as seen in Fig. 3.8 and Fig. 3.9.

Test Cases 43

Figure 3.8: Wireshark recording of DHCP starvation attack a

Figure 3.9: Wireshark recording of DHCP starvation attack b

The result of the attack can also be recorded with Wireshark, when the ids2 machine (withdynamic IP settings) is started. As can be seen from recording in Fig. 3.10 and the IPCONFIGsettings in Fig. 3.11 , the machine can not get an IP address, because the address space is filledup by the attack.While it is nice to see the attack working, our true aim is its detection. This is in this case arather hard task. In fact there are a number of ways to prevent these kind of starvation attacks.

Test Cases 44

Figure 3.10: Wireshark DHCP starvation, no answer to new dynamic device

Figure 3.11: DHCP starvation result: No IP for ids2

For instance by limiting the number of MAC addresses on each port of a server (if applicable)or by using a DHCP server, that uses the DHCP authentification [Dro11].Detection however is not possible with most signature based methods. One way to detectDHCP starvation might be statistical [Far11] approaches. One such software would be thespade preprocessor for SNORT. This plugin for SNORT was developed by silicon defensebut is now no longer available. Old versions are not recommended to be used. Most otherprograms employing statistical approaches are unfortunately commercial versions. Therefore,we can not present a working solution. We suggest that it should be easily possible to detectthat attack, by recording the frequency of DHCP attacks and comparing historical frequencywith current ones. Also it has to be considered that there are up to date methods, whichmake detection of such attacks a minor point, because the attacks are prevented from beingsuccessful.

Test Cases 45

3.4 Reconnaissance: Scans and Sweeps (Layer 2,3,4)

Since this report does not demonstrate one coherent attack, it lacked an important element,which is mandatory for most attacks to take place; Reconnaissance. The attacker has to getknowledge about the network he tries to intrude or compromise. In certain exceptions, thismight not be necessary because the attacker has preexisting knowledge about the network. Forinstance, if he himself was involved in it legally before. In any other case the attacker hasto perform a number of steps to gather knowledge. They can be different depending on whathe tries to gain and what tools he intends to use. Also, different ways might lead to differentamounts of information, while having a tradeoff for "noise". Noise in this case has a similarmeaning as to a burglar. Making noise will alert the owner of the house or in this case; It willalert security programs or personell.We demonstrate some scans that can be done using Metasploit since we are familiar with it atthis point. Similar scans and more can be done with nmap, which is one of the main tools forthese kind of scans.

3.4.1 ARP sweep

First it might be interesting to discover some IP addresses with an ARP sweep, using thearp_sweep module in Metasploit. A range of IP addresses has to be defined for doing so. Itwas chosen to scan the whole subnet.

use a u x i l i a r y / s c a n n e r / d i s c o v e r y / a rp_sweeps e t RHOSTS 1 9 2 . 1 6 8 . 5 6 . 0 / 2 4run

Metasploit will now send one ARP request for every IP in the network. It will report any IPthat responds as can be seen in Fig. 3.12

Figure 3.12: ARP sweep with Metasploit

3.4.2 TCP port scan

While the ARP sweep is rather fast, scanning for open TCP ports is slow. Thus we only doit for some of the detected IPs. Duration can be reduced if specific ports are searched, thedefault is 1-10000. Since we did not specify interesting ports for this specific test we kept thedefault. Another option could be to use multiple threads, by using "set THREADS X", whereX specifies the number of threads to use. Since our testing system is just a virtual machine,we also kept this at default with 1. These settings lead to about 10 to 15 minutes durations for

Test Cases 46

scanning one IP address. In reality it might be more reasonable to do smaller scans for specificports, which are of interest to the attacker. Thus these scans will be shorter and probably harderto detect. It has to be noted that the Metasploit TCP portscan module will keep looking forany non existing IP addresses, if they are part of the specified range. So it will not completeits job if a non existing IP address is in the range.

use a u x i l i a r y / s c a n n e r / p o r t s c a n / t c ps e t RHOSTS 1 9 2 . 1 6 8 . 5 6 . 1 0 0 −1 9 2 . 1 6 8 . 5 6 . 1 0 1run

With these settings Metasploit will try to send a SYN request to every IP in the list, for 10000different ports. This can be observed in the Wireshark recording in Fig. ??.

Figure 3.13: TCP scan with Metasploit, wireshark recording

This resulted into finding 3 open TCP ports for the ids1 (*.*.*.101) machine and no open portsfor the DHCP server (*.*.*.100), as shown in Fig. 3.14. It has to be noted that the host has anactive firewall, while the ids1 machine does not.

Figure 3.14: TCP scan with Metasploit

3.4.3 UDP port scan

After that a much quicker scan for UDP services was done, again with Metasploit.

use a u x i l i a r y / s c a n n e r / d i s c o v e r y / udp_probes e t RHOSTS 1 9 2 . 1 6 8 . 5 6 . 1 0 0 −1 9 2 . 1 6 8 . 5 6 . 1 0 1run

Test Cases 47

It is rather quick because it scans for some rather common UDP services, an excerpt of thescan is shown in Fig. 3.15.

Figure 3.15: Wireshark recording of UDP scan with Metasploit

Figure 3.16 shows that the scan finds two open UDP services in our network, both on the ids1machine. The same result could be observed if instead the udpsweep module is used In bothcases, nothing is found on the *.*.*.100 IP (DHCP server).

Figure 3.16: UDP scan with Metasploit, console screenshot

With SNORT two alert types are generated with the Signature IDs (SID) 402 and 1280:

[ * * ] [ 1 : 1 2 8 0 : 1 2 ] RPC por tmap l i s t i n g UDP 111 [ * * ][ C l a s s i f i c a t i o n : Decode of an RPC Query ] [ P r i o r i t y : 2 ]12 /13 −14 :06 :35 .359699 1 9 2 . 1 6 8 . 5 6 . 1 0 3 : 4 9 8 1 6 −> 1 9 2 . 1 6 8 . 5 6 . 1 0 0 : 1 1 1UDP TTL: 6 4 TOS: 0 x0 ID :9921 IpLen : 2 0 DgmLen : 6 8 DFLen : 40[ Xref => h t t p : / / www. w h i t e h a t s . com / i n f o / IDS428 ]

[ * * ] [ 1 : 4 0 2 : 8 ] ICMP D e s t i n a t i o n U n r e a c h a b l e P o r t U n r e a c h a b l e [ * * ][ C l a s s i f i c a t i o n : Misc a c t i v i t y ] [ P r i o r i t y : 3 ]12 /13 −14 :06 :35 .465670 1 9 2 . 1 6 8 . 5 6 . 1 0 1 −> 1 9 2 . 1 6 8 . 5 6 . 1 0 3ICMP TTL:128 TOS: 0 x0 ID :20141 IpLen : 2 0 DgmLen : 5 7Type : 3 Code : 3 DESTINATION UNREACHABLE: PORT UNREACHABLE

Test Cases 48

** ORIGINAL DATAGRAM DUMP:1 9 2 . 1 6 8 . 5 6 . 1 0 3 : 3 6 9 8 0 −> 1 9 2 . 1 6 8 . 5 6 . 1 0 1 : 1 4 3 4UDP TTL: 6 4 TOS: 0 x0 ID :9947 IpLen : 2 0 DgmLen : 2 9 DFLen : 1 Csum : 30128(1 more b y t e s o f o r i g i n a l p a c k e t )** END OF DUMP[ Xref => h t t p : / / cve . m i t r e . o rg / cg i−b i n / cvename . c g i ?name=2005−0068][ Xref => h t t p : / / cve . m i t r e . o rg / cg i−b i n / cvename . c g i ?name=2004−0790]

As can be seen, the scan accessed some unreachable ICMP port, which triggered the SID 402alert. The other alert is related to portmapper access (portmapper maps programs to ports andprotocols).So it is possible to detect certain scanning activities with signature based IDS. Additionally itmight be reasonable to use Honeypots for the detection, since any kind of discovery activitymight create traffic for the Honeypots in the network.

3.5 Detection with Honeypots

Honeyd is a freely available Honeypot software. It can be used to simulate a lot of differ-ent devices and services, thus trying to be as interesting as possible for an attacker. It doesnot simulate a whole operating system, but only specified services, so it is a low interactionHoneypot.For our purpose it is sufficient to start it without any kind of additional configuration likeshown here.

sudo f a r p dsudo honeyd

This way, honeyd together with farpd will take over any unused IP address in the network.Farpd will handle ARP requests, so that messages to unused IP addresses are actually directedto the Honeypot, which will then simulate (if configured) specific services. The most simpleway of testing is to ping a non-existing IP-address. As can be seen in Fig. 3.17 there is aresponse, even though the IP-address is not associated to any existing device.In fact there is not only one response, but multiple ones (indicated by DUP!). Also the responsetime is at 2 seconds for the first few pings. Both facts might make an attacker suspicious.Still, the traffic generated by the pings is useful in detecting an attacker, as any communicationwith non existing MAC or IP addresses is a possible attack. This could easily be used as a causeof alarm.Coming back to our UDP port scans described in the previous section, we tested if a UDPscan would raise alert messages with honeyd. At first a scan was done without honeyd orfarpd active. The result of this was that the ARP request during the scan did not yield anyanswer for the non existing IP. After activating honeyd and farpd the UDP scan would get portunreachable message from the device simulated by honeyd, indicating that the ports are notopen, but the machine is still up. This can be observed in Fig. 3.18.Figure 3.19 shows that honeyd generates messages for each connection attempt. They can beused as alerts and can even be sent by email.

Test Cases 49

Figure 3.17: Ping request and response to non existing IP with active honeyd and farpd

It has to be noted that farpd might produce conflicts with a DHCP server. If dynamic machinesare used on the network it might be reasonable to use other tools instead of farpd to route thetraffic to the honeyd machine.

3.6 SSL Man in the Middle attack

As a final more elaborate attack, we chose to make a proof of concept of a SSL man in themiddle attack. In detail it is attempted to compromise the communication between a client anda web server so that the attacker can see the encrypted messages in plain text.The approach used here is based on the webmitm tool which is part of dsniff. Other dsnifftools like arpspoof and dnsspoof are employed in the process. The concept of this attack isto compromise the connection between server and client from the beginning. That means theattacker first tries to use ARP poisoning to act as the internet gateway to the victim. Afterwardshe spoofs faked DNS entries, which link a desired DNS to the attackers IP. At this point theattacker can offer a faked SSL certificate to the victim and start a SSL session. Anothersecondary SSL session is started together with the target server. Thus instead of one validsession between victim client and target server, there are now two SSL sessions, with theattacker in the middle. Since he is part of both sessions he can encode and decode messagesto see them in plain text and route them from server to client or vice versa.To start the webmitm attack, it is recommended to enable IP forwarding first. This is done, asthe rest of the attack, on the ids3 virtual machines Ubuntu terminal:

echo 1 > / p roc / s y s / n e t / i pv4 / i p _ f o r w a r d

If the above doesnt work, this could be used to do so:

Test Cases 50

Figure 3.18: Wireshark recording and Metasploit outout during UDP scan with active honeyd

Figure 3.19: Honeyd ouput messages during UDP scan

sudo bash −c ’ echo 1 > / p roc / s y s / n e t / i pv4 / i p _ f o r w a r d ’

Test Cases 51

To test if IP forwarding is enable, you can check it with:

c a t / p roc / s y s / n e t / i pv4 / i p _ f o r w a r d

A result of one is for enabled, zero is for disabled.After that ARP poisoning can be started. This could be done with any tool, but for simplicitywe use dsniff in the whole process.

a r p s p o o f − t 1 9 2 . 1 6 8 . 5 6 . 1 0 1 1 9 2 . 1 6 8 . 5 6 . 1

This will start continuous poisoning of the ARP table in the ids1 machine, telling it that theMAC address of 192.168.56.1 (configured as gateway on ids1) is actually the MAC address ofids1 (192.168.56.101). As shown earlier, this can easily be detected with a tool like xARP, seealso Fig. 3.20.

Figure 3.20: WEBMITM attack: ARP poisoning detected by xARP

Now we should open a second terminal in Ubuntu and prepare for DNS spoofing. To do so,one could create a new dnsspoof.hosts file. Here an existing file was used, the default one wasused by dnsspoof. Search for it in the terminal by the following commands.

sudo f i n d / −name ’* d n s s p o o f * ’

Edit the file, for example with (with your real exact path to the .hosts file):

sudo v i d n s s p o o f . h o s t s

and add the following line to it:

1 9 2 . 1 6 8 . 5 6 . 1 0 3 g oo g l e . com

Finally use the following line to start dnsspoof. Enter the exact path of dnsspoof.hosts.

sudo d n s s p o o f −f d n s s p o o f . h o s t s

Test Cases 52

Figure 3.21: Screenshot of dnsspoof and arpspoof tool

That way a rouge DNS server is created, that will tell anyone who asks that google.com hasthe IP 192.168.56.103, which is the IP of the attacker. Figure 3.24 shows both arpspoof anddnsspoof running on Ubuntu machine ids3.To show that this is working, a DNS lookup was done on the targeted windows machine. Theresult can be seen in Fig. 3.22. It shows that the DNS request for google.com is answeringwith 192.168.56.103.

Figure 3.22: Looking up a spoofed DNS on windows, nslookup and wireshark recording

The final step is to start the webmitm tool in a new terminal.

sudo webmitm

The webmitm tool will ask the user for a number of information, which will be used forcreating the fake certificate, that will be presented to the victim client. This include informationlike company name, state or country as shown in Fig. 3.24 When this information is entered,the attack is started.

Test Cases 53

Figure 3.23: Screenshot of webmitm tool, entering certificate information

It will now route any requests from the ids1 machine to Google through the two establishedSSL sessions. That means if https://google.com is entered in the browser of ids1, thefake certificate will be offered to the user. At this point the attacker has to hope that the userwill trust the certificate and that the browser will not block it. In fact it can be seen in Fig. ??that Firefox warns the user that the certificate might indicate identity theft.This is as far as we tried since even the attacking machine was not connected to the web. It canbe seen that it basically works, although certain browsers might recognize that the certificateis spoofed, especially if there is another certificate in the browsers cache. It was observedthat a previously untouched installation of internet explorer 9 only warned about an unknowncertificate, but did not complain that it belonged to another website. The warning on IE waseven more problematic since it also included an "OK" message because the certificate wasindicated as up-to-date.Viewing this attack from the intrusion detection point of view, it is rather simple to handle,since it is largely based on the success of ARP spoofing. It shows that more elaborate attacksoften depend on low level problems, many of them depending on weaknesses in the ARPprotocol. Thus it can only be stressed that checking for ARP security on a network is veryimportant.

Test Cases 54

Figure 3.24: Certificate faked by webmitm in firefox

Results 55

4 Summary

4.1 Results

It could be observed that there is a high number of attacks and vulnerabilities that might en-danger networks. Some rather simple attacks, like ARP poisoning, are a basis for a lot ofelaborate approaches. Thus it is important to detect and in turn prevent them. Most of theattacks described here are based on more or less well known weaknesses in communicationprotocols and their implementation in network devices. While up-to-date protocols or devicesmight not be vulnerable to those older versions are often still in use.

Detection of attacks like ARP poisoning, MAC flooding, DHCP exhaustion or different dis-covery scans were presented in this case study. For this purpose a number of tools like xARP,SNORT and suricata were used. It could be observed that no tool detects every problem thrownat it. Successful detection was often possible with only one of those tools. For instance a ARPwatch like xARP should be used, even though SNORT includes an ARP preprocessor sincethe preprocessor is obviously working poorly.

Additionally to classical intrusion detection software, Honeypots in the form of honeyd wereused. They present not only opportunities to distract attackers but also to detect and analyzetheir behavior.

4.2 Problems

Considering the main interest of this case study, evaluating options to detect intrusion attempts,some problems occurred during the case study. The main issue is, that by using mostly signa-ture based intrusion detection systems some attacks will not be detected. The reason for this isthat certain attacks can very hardly be distinguished from normal network traffic (see DHCPexhaustion).The obvious solution would be to use statistical or anomaly based intrusion software. Thereseems to be a lack of such software concerning freely available systems. Commercial soft-ware like Symantec Critical System Protection [Sym12] are on the market but not availabledue their costs and so not tested here.Another problem or rather a limitation of most tools tested in this study is, that they are basedon well known signatures of rather old attacks. Statistical systems like mentioned above mightbe able to detect even new attacks (e.g. Zero-Day exploits). Another thing not considered isto detect attacks in heavily loaded networks, which we could not test in the simulated environ-ment we used. The increased number of normal network packets will increase the challengefor an IDS.

Results 56

4.3 Conclusion

As a final conclusion we would recommend, that a valuable system should not simply beprotected by using a single solution like SNORT or an integrated solution like suricata. Insteadof this it should be ensured, that ARP vulnerabilities are covered with tools like xARP andup-to-date signature based IDSs for any further well known attacks. To increase detectionchances beyond the performance of these systems, it is recommendable to use Honeypotsalongside any classical IDS. This can help to detect and distract attackers early on duringreconnaissance, regardless of the attack they plan to use once they find a proper target. Thecompletely different detection approach of Honeypots might serve to cover a bigger variety ofproblems. While it was not tested in the case study, the authors recommend to consider usingan IDS that is statistical or anomaly based.Of course this conclusion implies, that security managers should not only use several differentapproaches to intrusion detection. Intrusion detection should only be one part of a networkssecurity.There is a number of further things that improve network security:

• Regular updates of software or rule sets.

• Make use of up-to-date and more secure protocols or devices where possible.

• Do regular self-testing of security.

• Remove known vulnerabilities (for instance using port security on switches).

• Make use of firewalls.

• use VLANs, VPNs.

• Control physical access to network.

• Separate critical parts of the network from more open parts (internet, web services,wireless network), Demilitarized Zone DMZ.

• Deep Packet Inspection to scan for malicious content in packet data.

Summery and Forecast 57

5 Forecast

5.1 False Alarms

The behavior of "normal" or "expected" traffic on networks can not be predicted exactly, sincenetworks will experience changes like different connected devices or new software protocols.Irregular incidents might occur, which are not malicious but legitimate traffic. This can cause alot of false alarms, depending on how well a IDS is configured for its application environment.False alarms are to be expected for any system in the long run, but if their number is too high,they will desensitize the security personnel. People might start to ignore alarms in general, ifthey are experienced to be wrong in most cases. The other possibility is if alarms are used totrigger intrusion prevention measurements, high numbers of false alarms could significantlydeteriorate the networks performance.Thus further analysis could be performed on the IDS tools used here, to see how many falsealarms are created in a real-world application. Reduction of such false alarms to a reasonablylow number could be attempted.Additionally, researching tradeoff between rate of detection and false alarm rate in an exem-plary network situation, could be another interesting topic. One way of examining that tradeoffwould be the Receiver Operator Characteristic ROC, as indicated by [Ham07].

5.2 Statistical Anomaly-Based Intrusion Detection

As mentioned repeatedly in the report, statistical detection methods might yield results, wheresignature based methods fail. It could be of interest for future work to find tools, test themand see how well they can be applied to certain use cases. It could be interesting to havea look at the performance of such methods and also how their limitations affect detectionresults. O’Leary [O’L92] mentioned a number of limitations of statistical detection methodslike incorrect assumptions about distributions. Another limitation is the fact, that they needto learn what is "normal" in a network to detect anomalies based on statistical analysis. Thislearning phase can be difficult to implement. Additionally, false alarms are a considerableproblem, because statistical methods will never produce perfect results. This could add anotherinteresting point of research to the previous topic (false alarms). Threshold values, whichare parameters to be set in statistical IDS tools, are appropriate parameters to be varied forgenerating ROC curves. Thus they are ideal to perform a ROC curve based sensitivity analysis.

Summery and Forecast 58

5.3 Additional Vulnerabilities of Interest

5.3.1 Wireless

While Some of the attacks mentioned here will be a concern on wireless networks, too, wedid not consider wireless specific vulnerabilities in this case study. Such networks can hardlybe simulated in our testing environment and would require completely different setups, mostprobably with real hardware devices. Elsewise the development of a virtual environment forwireless network testing would be a new topic in itself.Regardless of this, it would be of interest to examine intrusion detection in wireless networks,since they are no rarity in industry any more. Many devices allow for wireless access and theflexibility this offers is often tempting to ignore the related security issues with such an openmedium. Therefore future work could examine some typical weaknesses of wireless networks.It was already outlined, that penetration testing tools (i.e. Metasploit) could support such testslike hidden node, DEAUTH or faked access points.

5.3.2 Session Hijacking

Another problem not dealt with in this report, which could be of interest for further studies, isTCP connection hijacking. Tools for penetration testing often include TCP session hijacking.Tests for other protocols employed in industrial networks could be of interest. For instancein [Kna11] it is stated that ICCP, a protocol frequently used in energy industry, is vulnerableto such hijacking attempts.

Bibliography 59

Bibliography

[Ato11] Atomic Software Solutions. Honeybot, 2011. http://www.atomicsoftwaresolutions.com/honeybot.phpOnline; accessed: 06.09.2011.

[Boy10] Tim Boyles. CCNA Security Study Guide: Exam 640-553. John Wiley andSons, 2010. ISBN 9780470527672.

[Bur02] Peter Burkholder. Ssl man-in-the-middle attacks, February 2002.http://www.sans.org/reading_room/whitepapers/threats/ssl-man-in-the-middle-attacks_480.

[chr11] chrismc. Xarp - advanced arp spoofing detection, 2011. http://www.chrismc.de/development/xarp/. Online; accessed: 02.10.2011.

[Dev] GroundZero Security Research Software Development. xray-ids.

[Dig11] Digininja. Metasploit dns and dhcp exhaustion, 2011. http://www.digininja.org/metasploit/dns_dhcp.php. Online; ac-cessed: 03.11.2011.

[DNVHC05] D. Dzung, M. Naedele, T. P. Von Hoff, and M. Crevatin. Security for industrialcommunication systems. Proceedings of the IEEE, 93(6):1152–1177, February2005.

[Dro11] W. Droms, R. Arbaugh. Authentication for dhcp messages, 2011. http://www.ietf.org/rfc/rfc3118.txt. Online; accessed: 03.11.2011.

[Far11] Jamil Farshchi. Intrusion detection faq: Statistical based approach to intrusiondetection, 2011. http://www.sans.org/security-resources/idfaq/statistic_ids.php. Online; accessed: 04.12.2011.

[Ham07] Rune Hammersland. Roc in assessing ids quality, 2007. http://rune.hammersland.net/tekst/roc.pdf. Online; accessed: 26.01.2012.

[HLR92] P. Helman, G. Liepins, and W. Richards. Foundations of intrusion detection.Computer Security Foundations Workshop V, Proceedings, pages 114 – 120,June 1992.

[JS11] R. C. Joshi and Anjali Sardana. Honeypots - A New Paradigm to InformationSecurity. Science Publisher, 2011. ISBN 978-1-57808-708-2.

[K.A01] K.A. Icmp attacks illustrated, 2001. http://www.sans.org/reading_room/whitepapers/threats/icmp-attacks-illustrated_477. Online; accessed: 08.01.2012.

Bibliography 60

[K.A11] K.A. Attacking the spanning tree protocol, 2011. http://ptgmedia.pearsoncmg.com/images/9781587052569/samplechapter/1587052563_CH03.pdf. Online; accessed: 08.01.2012.

[Kiz46] Joseph Migga Kizza. Computer Network Security. Springer, 2005, Part III,315-346. DOI: 10.1007/0-387-25228-2 12.

[Kna11] Eric D. Knapp. Industrial Network Security: Securing Critical InfrastructureNetworks for Smart Grid, SCADA, and Other Industrial Control Systems. Else-vier, 2011.

[Kra07] Harold F. Tipton; Micki Krause. Information Security Management Handbook.CRC Press, 2007. ISBN 9781420013580.

[Mah99] T. Mahesh. Middleware approach to asynchronous and backward compatibledetection and prevention of arp cache poisoning, August 1999. http://www.acsac.org/1999/papers/fri-b-0830-dutta.pdf. Online;accessed: 06.09.2011.

[Man03] Silky Manwani. Arp cache poisoning detection and prevention, Decem-ber 2003. http://www.cs.sjsu.edu/faculty/stamp/students/Silky_report.pdf. Online; accessed: 01.12.2011.

[Mat09] Michael E. Whitman; Herbert J. Mattord. Principles of Information Security.Cengage Learning EMEA, 2009. ISBN 9781423901778.

[Met11] Metasploit. Download metasploit, 2011. http://metasploit.com/download/. Online; accessed: 05.10.2011.

[Nat03] Jeff Nathan. Nemesis-rip, 2003. http://nemesis.sourceforge.net/manpages/nemesis-rip.1.html. Online; accessed: 15.12.2011.

[NB04] Martin Naedele and Oliver Biderbost. Human-assisted intrusion detection forprocess control systems, pages 216–225. 2004.

[New09] Robert C. Newman. Computer Security: Protecting Digital Resources. Jonesand Bartlett Learning. 2009. ISBN 9780763759940.

[nM08] verma nitin.; Mattord. Principles of Information Security. Course Technology,2008. ISBN 9781423901778.

[OCo01] TJ OConnor. Detecting and responding to data linklayer attacks, October 2001. http://www.sans.org/reading_room/whitepapers/detection/detecting-responding-data-link-layer-attacks_33513.Online; accessed: 08.01.2012.

[O’L92] Daniel E. O’Leary. Intrusion detection systems, 1992. https://msbfile03.usc.edu/digitalmeasures/doleary/intellcont/Intrusion%20Detecion%20and%20Continuous%20Auditing-1.pdf. Online; accessed: 04.01.2012.

Bibliography 61

[ORS] Online Resource ORS. Labrea: "sticky" honeypot and ids.

[OSS11] OSSEC (Observing System Science Executive Council) OSS. Homepage ofossec, 2011. http://www.ossec.net/. Online; accessed: 28.11.2011.

[Owe05] Sílvia Farraposo; Laurent Gallon; Philippe Owezarski. Network securityand dos attacks, 2005. http://spiderman-2.laas.fr/METROSEC/Security_and_DoS.pdf. Online; accessed: 12.12.2011.

[Sca10] Peter Scarfone, Karen; Mell. Guide to intrusion detection and prevention sys-tems (idps). Computer Security Resource Center (National Institute of Stan-dards and Technology), January 2010.

[Sec11] Accumuli Security. Ids / ips, 2011. http://www.accumuli.com/ids--ips-c-189.php. Online; accessed: 28.12.2011.

[Sym12] Symantec. Critical system protection, 2012. http://www.symantec.com/business/critical-system-protection. Online; accessed:05.01.2012.

[Vac10] John R. Vacca. Managing Information Security. Syngress, 2010. ISBN9781597495332.

[VP07] Eric Vyncke and Christopher Paggen. LAN Switch Security, What HackersKnow About Your Switches. Cisco Press, 2007.

[Wik11a] Wikipedia. Arp spoofing — Wikipedia, the free encyclopedia, 2011.http://en.wikipedia.org/wiki/ARP_spoofing. Online; ac-cessed: 18.10.2011.

[Wik11b] Wikipedia. Intrusion detection system — Wikipedia, die freie en-zyklopädie, 2011. http://de.wikipedia.org/wiki/Intrusion_Detection_System. Online; accessed: 12.11.2011.

[Wik11c] Wikipedia. Intrusion detection system — Wikipedia, the free ency-clopedia, 2011. http://en.wikipedia.org/wiki/Intrusion_detection_system. Online; accessed: 12.11.2011.

[Wik11d] Wikipedia. Ip address spoofing, 2011. http://en.wikipedia.org/wiki/IP_address_spoofing. Online; accessed: 18.10.2011.

[Wik11e] Wikipedia. Mac-spoofing — Wikipedia, die freie enzyklopädie, 2011.http://de.wikipedia.org/wiki/MAC-Filter#MAC-Spoofing.Online; accessed: 12.12.2011.

[Wik11f] Wikipedia. Port scanner — Wikipedia, the free encyclopedia, 2011.http://en.wikipedia.org/wiki/Port_scanner. Online; ac-cessed: 08.01.2012.

[Wik12a] Wikipedia. Honeyd — Wikipedia, the free encyclopedia, 2012. http://en.wikipedia.org/wiki/HoneydOnline; accessed: 12.09.2011.

Bibliography 62

[Wik12b] Wikipedia. Honeymonkey — Wikipedia, the free encyclopedia, 2012. http://en.wikipedia.org/wiki/HoneyMonkeyOnline; accessed: 06.09.2011.

[Wik12c] Wikipedia. Honeypot and forensic analysis tool — Wikipedia, the free ency-clopedia, 2012. http://en.wikipedia.org/wiki/Honeypot_and_forEnsic_Analysis_ToolOnline; accessed: 02.09.2011.

[Wik12d] Wikipedia. Honeypot (computing) — Wikipedia, the free encyclopedia, 2012.http://en.wikipedia.org/wiki/Honeypot_(computing). On-line; accessed: 26.01.2012.