Intrusion Detection Systems Matthijs Koot ([email protected]) Definitions, purpose Past and present How honeypots work HoneyD Honeynet, HoneyWall MWCollect: Nepenthes, HoneyTrap and HoneyBow Limitations and future Limitations Honeynet Research Alliance Future topics Summary Intrusion Detection Systems Lesson #4: Honey{pots,nets,walls} Matthijs Koot ([email protected]) Faculteit van Natuurwetenschappen, Wiskunde en Informatica Universiteit van Amsterdam 2007-04-12 / SNE-IDS college ’06-’07
39
Embed
Definitions, Intrusion Detection Systemsindex-of.co.uk/Various/lesson4_honeynets.pdfIntrusion Detection Systems Matthijs Koot ([email protected]) Definitions, purpose Past and present
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
DefinitionA honeypot is a sacrificial asset, either virtual or physical,whose purposes are to gather information on (and warnof) attacker behavior and to decoy attackers from realassets.
DefinitionA honeywall is a honeypot or honeynet that is placedin-line between two networks, or between a network anda host, to uni- or bidirectionally capture, control andanalyze attacks.
DefinitionA honeytoken is a honeypot which is not a computer.
In real life, ‘Honeynet" and “HoneyWall" are usedambiguously to refer to both their CONCEPTS, as well astheir prevalent IMPLEMENTATION (think ‘DNS’ versus‘bind’). This also explains any inconsistencies in (my) useof CaPiTaLiZaTiOn.
As proposed by Seifert, Welch, Komisarczuk in 2006,honeypots can be differentiated on...
I Level of interactivity (will be discussed shortly)I Data capture (attacks, events, intrusions, ...)I Containment (aka ‘data control’)I Distribution appearanceI Role in N-tier architectureI Communication interface (API, NIC, ...)
Sebek: spying on your intruderI From Honeynet.org: “Sebek is a tool designed for
data capture, it attempts to capture most of theattackers activity on the honeypot, without theattacker knowing it (hopefully), then sends therecoverd data to a central logging system."
I Recover keystrokes, uploaded files, passwords, IRCchats, even if they’re encrypted by SSH, IPSec orSSL.
Proceedings of the 2005 IEEEWorkshop on Information Assurance and Security
T1B2 1555 United States Military Academy, West Point, NY, 15 – 17 June2004
Towards a Third Generation Data Capture Architecture for Honeynets
Edward Balas and Camilo VieccoAdvanced Network Management Lab
Indiana University
Abstract— Honeynets have become an important tool forresearchers and network operators. However, their e!ec-tiveness has been impeded by a lack of a standard unifiedhoneynet data model which results from having multiple un-related data sources, each with its own access method andformat.
In this paper we propose a new data collection architec-ture that addresses the need for both rapid comprehensionand detailed analysis by providing two data access methods:a relational model based fast path, and a canonical slowpath. We also present a set of tools based on this architec-ture.
I. Introduction
A Honeynet is a network of high interaction honey-pots[1]. High interaction honeypots are quite different fromlow interaction honeypots such as Honeyd [2] for they pro-vide a full operating system and set of software for an in-truder to interact with. This high level of interactivity is adesired because it allows researchers the ability to observethe behavior of an intruder in a live system, and not a sim-ulation. As a result, high interaction honeypots are wellsuited to capture new or unanticipated activity. However,high interaction honeypots collect a larger volume detaileddata from multiple data sources making it difficult to man-age honeynets and make sense of the collected data.
To help facilitate honeynet deployments and the sharingof information between researchers, The Honeynet Projectstandardized the GenII honeynet architecture[3]. This ar-chitecture includes a specification of Data Capture proce-dures whose purpose is to “log all of the attacker’s activity”.The GenII Data Capture procedures specify the collectionof three types of data: firewall logs, network traffic andsystem activity. Figure 2 provides a schematic represen-tation of a typical Gen II deployment. This architecturedoes not provide any guidance on how to store or accessthe captured data.
In the standardized architecture, firewall logs are usedto provide a summary of the network activity. The“rc.firewall” script provided by the honeynet project al-lows this by using the Linux IPTables[4] connection track-ing capabilities. We feel this logging is counter-intuitivebecause firewall logs are typically used for policy auditingand in this case they are being used to provide summary
Fig. 1. GenII Honeynet Data Capture.
accounts of network activity. In addtion, these summarieslack needed detail such as the duration and quantity ofnetwork activity
Network traffic and Intrusion Detection System(IDS)events are captured using the Snort IDS system[5]. ForData Capture, two instances of are executed, one to merelyrecord the raw traffic, and the other to examine the net-work traffic looking for events that are indicative of misuseor intrusion.
System activity refers to monitoring activity from theperspective of each high interaction honeypot. This typeof monitoring includes two types of data: Syslog and Se-bek. Syslog data is provided by each honeypot’s operatingsystem. Sebek is a tool developed by the Honeynet Projectto monitor the behavior of intruder even when the intruderuses session encryption[6]. Sebek operates as hidden ker-nel module which covertly exports log data to the loggingsystem.
The GenII honeynet architecture gathers very detailed
To augment our understanding of the network activ-ity and the hosts at either side of a communication, weadded passive operating system fingerprinting capability,provided by the p0f[13] tool. P0f is also a pcap basedmonitor that provides an estimate of the operating sys-tem(OS) used by host that initiates a TCP connection.This data is useful for two reasons. First, across flows itallows one to see if the apparent host OS is changing for agiven IP source providing an indication that the host mightbe behind a NAT. Second, OS identification can improvethe accuracy of IDS events through the process of passivealert verification[14][15]. For instance in a situation wherea apache mod ssl exploit[16] is launched against a non-linuxhost, the system could detect this discrepancy and treat thealert with a lower priority similar to the approach taken byRNA[14]2.
The addition of the Argus and p0f data to the Snortand packet capture data provides a more comprehensiverepresentation of events than provided in the GenII design.Further this new data can be organized around the conceptof a network flow. However additional data sources areneeded to bridge the relational gap between the networkflows and processes on a host.
To bridge this gap we enhanced Sebek [6] to monitor net-work activity from the host’s perspective. Sebek is a kernelbased data capture tool designed to be installed on high in-teraction honeypots [1]. Balas modified Sebek to monitorsocket, process and file activity [17]. These modificationsprovided three necessary capabilities.
First, Sebek was enhanced to monitor socket activity.Whenever a honeypot accepts or creates a network con-nection, Sebeck records the IP level attributes as well asthe corresponding host, process and inode. This allowsus to relate a network flow to the specific open inode andfile descriptor used by a process to service the connection.This data is integral to providing a composite view of theincident that transcends flow and host data. Once a net-work connection associated with an intrusion attempt is ob-served, we immediately know which inode and process theintrusion was tied to. Using this data we can quickly iden-tify related information such as the keystrokes captured bySebek.
Second, Sebek was enhanced to monitor process creation.This monitoring allows us to relate one process to another,rebuilding the process tree. This is important in intru-sion analysis for it allows us to track the intrusion forwardfrom the point of intrusion identifying all processes cre-ated, and any other causally related system activity, suchas outbound network connections[8]. The same capabilitycan be used in reverse, if we see an outbound connectionon a honeypot, we can back track to identify the point of
2p0f can only estimate the OS of the TCP initiator, in this examplethe OS of the host under attack is known by either manually intro-duction of the OS by part of the administrator as with a honeypot orthrough previous TCP connections initiated by the particular host
Honeynet Ethernet
Raw Socket
libpcap
P0f
Passive
OS
detector
Snort
Intrusion
Detection
System
Argus
Flow Monitor
Sebek
Data Collector
Traffic
Recorder
Hflowd: Data Fusion
Relational Data Access Raw Data Access
Deamons
Kernel
Hflow DB Pcap
Fig. 3. Data collection and fusion diagram
intrusion.Lastly, the ability to monitor the opening of files was
added. Coupled with the process tree this allows us to iden-tify all files accessed as part of an intrusion. This knowledgecan in turn be used to prioritize data analysis e!orts. Asan example, presume that a specific intruder likes to placehis/her files in a unique location in the file system. Oncethis location is identified, we can quickly search preexistingdata for any prior indications of the same intruder’s pres-ence. This capability can also be used to create a crudeform of Honeytoken[18] where the act of accessing a cer-tain file might be deemed an interesting event requiringfurther investigation.
B. Data Fusion
Hflow was developed to combine each of these datasources into a composite relational model. It continuallyconsumes data from each source, fusing it based on iden-tifiable relationships and it then loads this data into adatabase.
Hflow receives Argus flow, Snort IDS, p0f OS fingerprintsand Sebek data. This data once combined is then insertedinto a database.
Flow related data, such as Argus and Snort, are corre-lated based on corresponding tuples consisting of the IPprotocol number, the source and destination IP addressesand if applicable port numbers which fall within the same
Honeynet Research AllianceI “The Honeynet Research Alliance is a trusted forum
of other honeypot research organizations. [...] Theseorganizations subscribe to the Alliance for thepurpose of researching, developing and deployinghoneypot related technologies and sharing thelessons learned."