the honeynet quarantine

8/9/2019 The Honeynet Quarantine

1/7

Anomaly based intrusion detection is inherently subject to false

alarms. Fast and automated intrusion response based on this

type of intrusion detection will cause significant usage

restrictions for falsely suspected systems. To avoid these negative

effects without sacrificing detection sensitivity or increasing the

risk for the production network inadequately, we propose a

scheme combining anomaly-based IDS with Honeynet concepts

and link layer based VLANs. In addition to introducing the

concept, we will describe a proof-of-concept implementation and

report results from some lab tests confirming the benefits of this

approach.

I. INTRODUCTIONOver the last few years mobile computing and wirelessaccess has significantly changed the situation in corporate

networks. While some years ago the single entry point, i.e.the router attaching the network to the public internet, could

be appropriately secured by firewalls, nowadays there aremultiple, often hard to control entry points to the LAN.Moreover, internet worms and viruses [3] have learned to

spread over networks within a few minutes. If notebooks,

tablet PCs, handhelds and smartphones are used in non-secured areas, e.g. in home networks or in public networks

on the road, their security cannot be fully controlled by the

corporate system administrator. When exposed to theinternet without tight protection, these systems can be

infected with worms within a couple of minutes [4] [5].

Attaching an infected device to the corporate network cancause rapid spreading of the worm inside the LAN.Therefore, the application of Intrusion Detection (IDS) [1]and Intrusion Response systems (IRS) in addition to

classical firewalls has become more and more crucial.

IDSs are per definition passive systems. Their task is alarmgeneration rather than system protection by data filtering or

by repairing the file system. Hence, human intervention is

required to reinstate network integrity. IDSs either use rulebased detection approaches (misuse detection) or they try todetect deviations from normal operation, also known as

''anomaly detection'' [6]. While the first approach onlydetects well known attacks based on predefined signatures,the latter one is also able to detect previously unknown

attack patterns based on deviations from normal systemand network behavior. However, as normal behavior is

not fully defined and may change dynamically falsealarms (false positives) are generated at a certain,sometimes significant, rate. This limits the usefulness of

active, automated Intrusion Response Systems trying to

protect the network by e.g. shutting down suspicious processes or disabling network connections on affectedsystems. In case of a false positive IRSs will cause

collateral damage by impairing or even deactivatinginnocent hosts. For example the peer-to-peer based voice-over-IP Software Skype [see http://www.skype.com]

performs regular peer lookups by scanning IP addresses. AnIDS will typically rate this as viral or worm-like behaviorunless there is a specific rule set for Skype. Therefore, a

tightly configured IRS would deactivate thiscommunication or even disconnect the offending system

from the network.To avoid these negative effects without sacrificingdetection sensitivity, we propose to combine intrusion

detection and response with mechanisms known fromHoneynets [4]. In our approach, suspicious systems are not

disconnected totally but automatically quarantined in aspecial network section which basically is a Honeynet by using VLAN technology. There they can be observed in

a controlled environment before making a final decision.During quarantine, the suspicious systems are allowed some

limited, tightly controlled access to the production network.By defining the allowed level of access to the network, therestrictions for falsely suspected systems can be balanced

out with the risk generated for the network by quarantinedsystems. Our proposed solution thus offers a differentiated

defense against rapid worm propagation inside localnetworks.In section II of this paper, this concept is introduced more

detailed. Section III presents a first prototypeimplementation which demonstrates the feasibility of theconcept while section IV provides first results from lab tests

and measurements.

II. THE HONEYNET QUARANTINETypical production networks are not protected by

sophisticated HIDS installed on every workstation attachedto them due to the effort that has to be spent and theexpertise that is required and therefore intrusions on these

end systems will not be detected at first. As a consequence,autonomous malware may spread without control if a

mobile, infected system is reconnected to the production

The Honeynet Quarantine: Reducing Collateral

Damage Caused by Early Intrusion Response

Birger Tdtmann, Stephan Riebach, Erwin P. Rathgeb

Computer Networking Technology GroupInstitute for Experimental Mathematics

University of Duisburg-Essen, Germany

{btoedtmann,riebach,erwin.rathgeb}@iem.uni-due.de

Proceedings of the Sixth International Conference on Networking (ICN'07)0-7695-2805-8/07 $20.00 2007


2/7

network and it is necessary to identify and disconnect sucha system as soon as possible.Our approach is to reliably identify compromised systems

by automatically connecting them to a Honeynet with itssophisticated HIDS sensors autonomous malware thatinfects a Honeypot is far easier to detect than doing so in a

noisy production environment. However, this automatedinvestigation takes time. In order to provide the user of the

system with some basic service during the investigation butat the same time shielding the production network fromfurther infection, our concept is to isolate a computer

system fast and automatically when an anomaly-basedNIDS reports suspicious activity, but in a soft manner, i.e.without completely disconnecting it from the production

network. This reduces the damage incurred if the systemwas falsely reported. When quarantined in such a way, theHoneypots exposed to the system will either confirm or

deny a successful attack such as a viral infection after a

predefined holding time. As a result, the restrictions for theuser of the potentially compromised system are kepttolerable while an in-depth evaluation of the incident is

undertaken and the production network remains protected. 1

Our solution is thus twofold: in the first part, the incidentreport of an anomaly-based NIDS is used to trigger an

isolation procedure that partly removes the offendingsystem from the production network, still allowingharmless, preconfigured traffic back into it while diverting

all other traffic to the quarantine network. The second partis to expose (one or more) Honeypots that have been

configured like a typical production system and are thusvulnerable to the same exploits directly to the suspectedmachine. If one of the Honeypots is then being

compromised successfully, its HIDS will report it and theisolation procedure is triggered again, this time to entirely

remove the compromised system from the network. If, onthe other hand, no further attack attempts are being reportedfrom the Honeypots, the isolated system is released back

into the production network.

A. Central monitor and investigation systemWe start with a NIDS that is enhanced to provide a more

sophisticated monitoring and incident investigation system.It contains a modified NIDS sensor, an attachment pointmapper and a configuration function to isolate, disconnect

or rehabilitate systems in the production network.Furthermore, it connects to a Honeynet where quarantinedsystems are moved into. This could even be implemented

on the monitor and investigation system itself by usingvirtualization software such as VMware [23].

B. Anomaly detection sensor with two thresholdsA commonly used scheme for anomaly based intrusion

detection is to measure the relative frequency by which aspecific activity x occurs and use it as an estimate for the

1The principle of isolation and verification of an initial suspicion is alsowell known from controlling epidemics and identifying criminals, where it

is quite successfully applied.

probability P(x) of its occurrence. After thesemeasurements, which are sampled during a training phase,an activity is assumed to be an anomaly if its occurrence

deviates too much from the normal frequency. Therefore, adefinition of a threshold by the IDS administrator isnecessary this threshold is consequently also responsible

for the rate of false positives and false negatives.. In orderto allow for a more sophisticated, two-phased intrusion

detection scheme as outlined above, we modify theanomaly assessment of the detectors to supply two

thresholds that distinguish three areas:

Normal: Anomaly indicator below lower threshold,event is definitely rated as normal activity

Suspicious: Anomaly indicator between lower andupper threshold, further observation in the quarantinenetwork is initiated.

Alarm: Anomaly indicator above upper threshold,event is definitely rated as dangerous; countermeasures(e.g. shutdown of the switch port) are immediatelyinitiated.

C. Attachment point mapTo perform a fast isolation of suspicious systems and (as far

as possible) transparent for running applications there, we propose to use Virtual LANs (VLANs) which is most

convenient as our concept so far only covers Ethernetnetworks. VLANs can be maintained in complex,

hierarchical switched-LAN topologies if IEEE standard802.1q is applied. Now, as a prerequisite for rapid isolationusing VLANs, the switch port to which the suspicious

system is attached has to be identified. We do this byutilizing the Simple Network Management Protocol(SNMP, [11]) to reliably extract the physical access port

from the switch topology. However, as the query and

response processes as well as the correlation of the resultingdata takes some time, we use a proactive approach where

all systems are mapped from their respective IP and MACaddresses to ports when the initially connect to the

network.2

D. Isolation and rehabilitationAs mentioned before, we put suspicious systems intoquarantine by moving them into a special preconfigured

quarantine VLAN. A prerequisite is that all switches areIEEE 802.1q enabled, i.e. the switches are able to recognize

the VLAN tags and will process them accordingly. Thequarantine VLAN ensures that all data packets from an

isolated system are tagged accordingly and are forwarded based on these VLAN tags to the central monitoringsystem. From there they are relayed either to the quarantine

network or the production network, depending onpreconfigured forwarding and filtering rules.

2 In case several systems are connected to the same port via a hub, thewhole segment attached to the port is isolated if necessary. Ifauthentication mechanisms on the link layer are used in the network, e.g.IEEE 802.1x [13] and EAP [14], locating the systems is even simpler

because the relevant information is explicitly exchanged in these protocols.



3/7

Depending on the result of the investigations carried outduring the confinement, the isolation/rehabilitation functionis instructed to either finally disconnect the suspicious

system completely from the production network by shuttingdown the physical switch port, or to reconnect it to the production network by moving it to back the default

VLAN.

E. User-friendly traffic switchAs a result, we have established three distinct network partitions which are connected to the central monitoring

system: The production network (default VLAN), asegment which contains suspicious systems separated from

the production network (quarantine VLAN) and theHoneynet.

A filter logic within the monitoring system now defineshow the packets are forwarded in a user-friendly, butprotective manner:

All 3 network partitions belong to a common bridge Traffic originating from the suspicious system that has

been classified as harmless based on predefined rules isallowed back into the production network

All other (potentially dangerous) traffic generated by thesuspicious system is diverted to the Honeynet

Traffic from both production network and Honeynetdestined to the suspicious system is delivered there

All traffic between the production network and theHoneynet is blocked.

In such a scenario, a basic service can be provided to the

isolated system during the quarantine period. The potentialrisk for the production network emanating from theapplications classified as harmless can be further minimized

by using a local Intrusion Prevention System, e.g.

snort_inline [15]. With this extension, Snort can modify themonitored traffic in such a way that specific attack patterns

are normalized.3

F. Quarantine investigationThe quarantine VLAN is, through the rules describedabove, directly connected to the Honeynet, where the

Honeypots represent typical systems similar to those foundin the production network. This reflects the actual threat

level for the production network.Due to their HIDS sensors which can safely report almostany activity going beyond the usual internal system

maintenance as an intrusion, the Honeypots are able to

verify the intrusion of the suspicious system quickly andreliably (as it is the only source of an attack) and will reportit to the central monitoring system. It is crucial for theeffectiveness of the overall concept here that the HIDS

should operate with a low latency, i.e. rather than onlyperforming periodic checks of MD5 checksums [8], tighter

monitoring of local process activity, disk and (system) fileaccess is necessary. These techniques provide the

3This makes sense especially if email is still allowed, to avoid spreadingof viruses that use this as t ransport mechanism.

quarantine network and its Honeypots with examinationand observation capabilities way beyond those feasible inthe production network. Compromised Honeypots should

be automatically restarted with a clean configuration oncethe isolated system has been removed from the Honeynet.

G. Quarantine timerThe partial isolation of suspicious systems is controlled by

a timer which is preconfigured by the network administratorto balance out the detection accuracy and the restrictionsimposed on the isolated systems. If no attack activities are

detected on the Honeypots during this time period, it isassumed that the suspicion was unsubstantiated. The system

is moved back to the production network in this case and,thus, fully rehabilitated.

III. PROTOTYPE IMPLEMENTATIONWhereas the conceptual approach is quite straight-forward,

the technical details are more complicated, as first lab trialsdemonstrate. In order to show the feasibility of the ideas

that have been outlined above, we set up a small testscenario. There, we attached a first prototype of ourmonitoring system and conducted several tests that

demonstrate that the basic functionality is available and alsoyielded measurements on the performance of the solution.We used Cisco switch equipment to provide the link layer

network infrastructure, WindowsXP systems for the clientsand a Linux system as central monitoring and investigationsystem for IDS, rapid isolation and Honeynet quarantine.

As illustrated by Figure 1, the production Ethernet networkis in VLAN 2,4 whereas the quarantine VLAN has beengiven the ID 3.

honeypot(VMware)

trunk

trunk

monitor &investigation

system

(bridge)

productionnetwork

(VLAN2)

quarantine

network

(VLAN3)

suspicioussystem

Fig. 1: User-friendly system isolation and intrusion

investigation by Honeypot exposure topological view

The switches were configured such that trunk ports use

802.1q VLAN tagging. The monitoring system was alsoattached to a trunk port, there we set up two pseudo-

interfaces, one belonging to VLAN 2 (eth0.2), the other to

VLAN 3 (eth0.3). Under normal operation, VLAN 3 is

rather inactive as the only system participating in thisVLAN is the monitoring system itself.

4The reason to use VLAN id 2 instead of the default VLAN (untagged) isthat Linux is not able to bridge between a non-VLAN interface and aVLAN pseudo-interface if it has the non-VLAN interface as physical

parent.



4/7

A. Snort/Spade configurationAs NIDS to look out for anomalies occurring within the

network we used the toolset Snort/Spade. Spade is ananomaly-based detection plugin for Snort that can be given

an anomaly score threshold and will report an incident if itobserves network activity whose anomaly score exceedsthis threshold [10]. For the first prototype, we did not

enhance the Spade engine to offer a two-threshold reportingscheme but simply used it with one threshold set at its

default value. Thus we had no upper bound which couldindicate a definite incident but had rather a huge marginof suspicion (the other threshold then being, by definition,

infinite).5 The Snort process was then set up to reportincidents via the syslog mechanism available in Linux,

which in turn was configured to deliver alert messages fromSnort to a named pipe /hq/snortreport to which ourmonitoring and investigation procedure honidsctl was

attached:

eth0.2 snort sysklogd /hq/snortreport honidsctl

B.Arpwatch combination with SNMP

We used the program arpwatch to detect newly activatedsystems within the network [20]. When arpwatch sees a

new station, we call a script mac2port (this is done byusing the -s switch available in the Debian version of

arpwatch) that then automatically extracts the attachment point, i.e. the port to which the new system has beenattached, by use of SNMP requests to all switches.6 Atworst we have to issue three requests and wait for three

responses for all switches in the network to obtain a valid

result. We then save the information :: in a file with the IP address of the system as

filename for later use by the isolation/rehabilitationfunction:7

eth0.2 arpwatch mac2port /hq/

C. Isolation/rehabilitation control with SNMPWhen Snort/Spade flags a suspicious system, our controlprocedure can thus look up the switch and the port of theoffender and move the system into the quarantine VLAN by

sending a SNMPv3 set request to the switch which

contains vmVlan. as OID and the new VLAN id3 as value. A second message has to ensure that the

corresponding MAC address is cleared from the internal

5 One could also get a two-threshold Snort system by setting up twoSnort/Spade processes with differing threshold configuration: if only oneof them reports an incident, the suspicious area is flagged.6This is accomplished by issuing three SNMPv3 requests obtaining OIDsfrom the Bridge- and Interface-MIBs: the dot1dTpFdbPort.OIDwill contain the bridge port of the system with the observed MAC address;the corresponding ifIndex of the Interface-MIB can be mapped from the

dot1dBasePortIfIndex. and by reading vmVlan.from Ciscos VLAN-MEMBETSHIP-MIB we can assess whether thefound port is a trunk port (which is then not the attachment point because itwill never be on a trunk).7This procedure will have to be refined in the future as spoofing IP andMAC addresses by an attacker may currently result in huge file system

bloat.

MAC table of the switch.8 The performance of thisoperation depends on the speed of the network and isusually completed within a second as it takes almost no

time at the switch.

qtimer

/hq/snortreport honidsctl snmpset

/hq/

We thus ensured that upon Snort issuing the first alert

(under slight network load this is done between 1-2 secondsafter observing the suspicious activity), our mechanismisolated the corresponding system very fast and efficiently.

Furthermore, the control program fires up a timer(qtimer) that will trigger the rehabilitation function after20 minutes by using a named pipe called notguilty:

qtimer /hq/notguilty honidsctl snmpset

The control program will then, with similar SNMPmessages as used for isolation, move the port back into

VLAN 2. A third named pipe, called guilty, will informthe control program to shut down the offending system incase of a confirmed compromise it is used by the HIDS

observing the Honeypot (see below):

grep /hq/guilty honidsctl snmpset

VMware reboot

D. VMware-based Honeypot and HIDS setupWhereas a full-fledged, non-virtualized Honeynet may have

its benefits, we decided to use a simple VMware Honeypotfor our prototype which had the same WindowsXP version

installed as our production clients had. Besides simplicity,VMware and Usermode Linux provide efficient ways to re-initialize Honeypots after they have been compromised

which was of more importance than forensic investigationson the inner workings of a caught virus. We thus usedVMwares methods to make the working disk of the guest

system non-persistent, which means that changes to the diskimage made by the guest operation system will not be

written to the original file but to a so-called REDO file.This not only provided us with a mechanism to clean acompromised Honeypot very easily (by simply rebooting it

from the original, write-protected image file), it also madefinding unauthorized file access much faster because onlythe REDO file had to be investigated for filesystem

changes. In order to accomplish this, we had to install the

WindowsXP that serves as the guest system into a FAT32filesystem because the NTFS filesystem is not very suitablefor finding differences. In fact VMware writes singlesectors that have been changed by the guest to the REDO

file, thus it contains not a filesystem but only small parts ofit. However, with FAT32 it is possible to observe the

names of newly created files within the guest system. We

8 Many switching products cannot handle the same MAC address indifferent VLANs because they dont maintain separate MAC addresstables per VLAN. This has to be considered when building such a link

layer based isolation system.



5/7

implemented this by periodically making a copy of theREDO file and letting the utility xdelta compare both filesafter 10 seconds:

/hq/vmpot.vmdk-s001.REDO_7JhTOS.10s-ago

vmware /hq/vmpot.vmdk-s001.REDO_7JhTOS xdelta /hq/vmpot.vmdk-s001.REDO_7JhT.delta grep /hq/guilty

This very simple HIDS running on the VMware host (ourLinux system) was able to detect several different virus

infections by observing new .DLL and .EXE files written to

the REDO log via the simplegrep utility.

E. Bridge and filter configurationIn order to transparently forward traffic on the link layerbetween the three network partitions, we enabled bridging

within the Linux system and attached the three interfaces

eth0.2, eth0.3 and vmnet1 to the bridge interface br0using the brctlprogram. Now, to enforce the confinement

of a system that has been moved to the quarantine VLAN3,we configured the Linux packet filtering software netfilter

via utilities iptables and ebtables [21, 22] in such a way thatonly DNS, WWW and SMB traffic is allowed to pass from

eth0.3 to eth0.2, thus leaving the quarantine network andentering the production network:

# allow arpebtables -t nat -A PREROUTING -j ACCEPT --in-if eth0.3 --protocolarp --arp-opcode Requestebtables -t nat -A PREROUTING -j ACCEPT --in-if eth0.3 --protocolarp --arp-opcode Reply

honeypot(VMware)

monitor &

investigation

system

(bridge)

production

network(VLAN2)

suspicioussystem

ARP requests

and replies

Fig. 2: Step 1 - bridge ARP packets transparently to

enable MAC address lookup

This allows all systems to look up each others MACaddress transparently without further interference. When in

the next step the suspicious system wants to connect to aproduction system, our traffic switch differentiates between

harmless traffic and all other redirected to the Honeypot (asillustrated by Figures 2 and 3):

# allow certain production services (dns, shares, web) to bereached

ebtables -t nat -A PREROUTING -j ACCEPT --in-if eth0.3 --protocolip --ip-destination 0.0.0.0 --ip-protocol 17 --ip-destination-port53iptables -t nat -A PREROUTING -j ACCEPT -m physdev --physdev-ineth0.3 --destination 0.0.0.0 --protocol udp --destination-port 53ebtables -t nat -A PREROUTING -j ACCEPT --in-if eth0.3 --protocolip --ip-destination 0.0.0.0 --ip-protocol 6 --ip-destination-port139iptables -t nat -A PREROUTING -j ACCEPT -m physdev --physdev-ineth0.3 --destination 0.0.0.0 --protocol tcp --destination-port 139ebtables -t nat -A PREROUTING -j ACCEPT --in-if eth0.3 --protocolip --ip-destination 0.0.0.0 --ip-protocol 6 --ip-destination-port80iptables -t nat -A PREROUTING -j ACCEPT -m physdev --physdev-ineth0.3 --destination 0.0.0.0 --protocol tcp --destination-port 80

honeypot

(VMware) monitor &

investigation

system(bridge)

production

network

(VLAN2)

suspicious

system

harmless

traffic

Fig. 3: Step 2a bridge harmless traffic to production

network (VLAN2)

The redirection of traffic towards the Honeypot has to bedone in a bit more sophisticated way as we need to

exchange the destination IP and MAC addresses of packetscoming from the suspicious system to be forwarded to theHoneypot system with IP address 10.0.0.1 and MACaddress 00:0c:29:a2:e3:63 (which is a WindowsXP system

and has no Honeyd functionality to attract all traffic to it):

# DNAT all other traffic to Honeypot (IP & MAC)ebtables -t nat -A PREROUTING -j dnat --in-if eth0.3--to-destination 00:0c:29:a2:e3:63

iptables -t nat -A PREROUTING -j DNAT -m physdev --physdev-ineth0.3 --to-destination 10.0.0.100

This allowed us to safely bridge all traffic from eth0.3 to

vmnet1, through which the Honeypot is connected with the

Linux VMware host, without reconfiguring the network ofthe Honeypot all the time. On the other hand, when theHoneypot now sends response packets back to the

suspicious system, we can switch the source IP addresses back by using Linux connection tracking mechanism.

However, the source MAC addresses cannot be reinstatedas the Linux netfilter system currently does not supportconnection tracking on the link layer. This will not affect

the applications running on the systems but may servemalicious code to detect our detour to the Honeypot.

honeypot

(VMware)

monitor &

investigationsystem

(bridge)

production

network(VLAN2)

suspicious

system

Fig. 4: Step 2b packets not matching the harmless

filter specification are redirected towards the Honeypot

using DNAT on the link and network layers

The last matching rule in our filter setup was then to dropall other packets, this in fact prohibits any traffic to be

forwarded between vmnet1 and eth0.2.

The bridge and filter configuration for the prototype is setup when the enhanced monitoring system boots up, together

with Snort and the VMware guest system that is alsoautomatically started.



6/7

IV. EVALUATIONIn first tests we were able to validate the basic functionalitywhich served the user reduced but tolerable access when

being quarantined after firing up Skype. As Skype wasstarted on a client system, it began to scan for peer nodes.The Snort/Spade engine flagged this activity within 2-3

seconds and the honidsctl program subsequently moved

the client system into VLAN3 within a second. We werethus able to react within at least 5 seconds to shield the

production network from further activity of a suspicioussystem.9 However, the client was still able to successfully

access shares on a file server as well as webpages from theInternet. As the periodically executed xdelta and grep didnot report newly created .DLL and .EXE files within the

disk of the VMware Honeypot, the honidsctl programmoved the system back into the production network after 20

minutes.We then set up a client system that contained an activeLovesan.A virus and connected it to our test network. Snort

this time also detected the infection attempts of the virusand the corresponding system was isolated from the

production network. As the virus continued its spreadingattempts, we could observe the creation of the file

MSBLAST.EXE within the REDO file of the VMwareguest. Consequently, the compromise had been confirmed

and the client was entirely disconnected by honidsctl via

SNMP, administratively shutting down its access port. Thiswas a successful proof that an unconfirmed anomalyobserved in a noisy environment could be investigated more

thoroughly in a controlled, clean environment while at thesame time not impairing the usability too much.

A. Timing considerationsTo find a lower bound for the performance of the system

that has to be reached in order to reliably contain viralspread, we measured the time a typical worm needs toinfect another system. Therefore we placed two non-

persistent VMware guests (Windows XP) in a LAN andstarted different internet worms on one of them. To cope

with the fact that most worms attack randomly generatedaddresses we used DNAT to directly forward attack packetsto the victim host, not depending on the actual destination

IP address the virus calculated. We activated differentinternet worms with some variants10 and monitored theirbehavior with a packet tracing program. By measuring thetime from the first packet observed from the infected

system destined to the victim system until this was

successfully compromised and started to spread the worm

itself, we established some estimates for fast viral infection(each sample was taken three times):

Test 1 Test 2 Test 3

Lovesan.A 13 sec. 16 15

Lovesan.F 14 sec. 11 16

9 This performance, however, depends largely on the network load asSnort is much slower when it needs to monitor a large amount of traffic.10 The viruses were obtained from http://vx.netlux.org, which is wellknown as a virus repository.

Sasser.A 5 sec. 4 6

Sasser.B 9 sec. 8 7

Welchia

A,E,G,H

Randex.I

After activation all variants were

inactive for at least 5 minutes

Table 1: Spreading time of well-known worms

This indicates that if a virus were to target an adjacentsystem in the same network, a response system aimed at

effectively quarantining the virus host must do so in atleast 4-5 seconds. Our prototype currently suggests that thismay be achievable, especially when the network is not

loaded as this affects Snort performance. Note that virusesright now do not target systems in the same network but

rather spread randomly, which gives a quarantiningfunction a lot of more time than this lower bound suggests.We have for now skipped virus behavior where the

malware is rather quiet and only goes active from time totime, this will be covered in a long-term study.Furthermore, we did not consider the fastest worm seen

ever, the SQL slammer, as it for now exceeds the

performance capabilities of our detection and isolationsystem.

B. LimitationsCurrently our prototype is supporting one broadcast domainas VLANs cannot spread beyond a subnet. The VLANswitching with SNMP is working, but this confines the

solution to special switch equipment offering VLAN-specific MIBs. Furthermore, the anomaly detection withinthe VMware host is still sketchy, from time to time, the

.EXE and .DLL extensions of newly created files could notbe found in the REDO file reliably (maybe because the filename resides in more than one disk sector). The HIDS also

is solely based on manipulations happening in theHoneypots filesystem, a process monitoring mechanism

would be suitable as well.Our control procedure currently supports the isolation andinvestigation of only one suspicious system at a time.

Multiple incident handling while maintaining the Honeynetfunctionality of a controlled, clean environment is non-

trivial, as for each suspicious activity separate VLANs andHoneypots then have to be set up to avoid interference.Another open issue is the yet missing integration of users

and administrators. As users might start offending (butharmless) applications frequently, quarantine andrehabilitation of their systems will happen again and again

until an administrator can provide the triggering NIDS with

the signatures needed to suppress the corresponding alerts.

V. FUTURE WORKAs the proof of work presented here suggests that using

Honeynet functionality to enhance IDS accuracy is a promising approach, we will address some of the issuesoutlined above. Namely a notification mechanism for the

users will be integrated into the system as they can help toincrease the detection quality quite significantly only



7/7

users can observe the causal connection between theiractivity and the quarantining process: Whenever I click onthis icon, I get a message saying that my system is now

quarantined and I will only be allowed to access the internalweb pages. Further working items are to stretch theisolation procedure over subnet boundaries by using

techniques such as L2TP or Ethernet over MPLS, and theimplementation of investigative threads enabling multiple

incident handling.

VI. CONCLUSIONSIn this paper we have demonstrated a way to improve LAN

security, especially to contain the spreading of worms, byimplementing an enhanced two-phased anomaly-basedintrusion detection and response system using Honeynet

technology to validate malicious intent. The system is user-friendly as it still offers a reduced but tolerable connectivity

to the network while the second-stage investigation isundertaken. This has the potential to increase bothacceptance for IDS deployment and detection accuracy.

While the IDS and Honeynet communities are still

somewhat disjoint because of the diverging areas of interestof those groups (Honeynets are still mainly used forforensics and hacker behavior studies whereas IDS/IRS areused to actively make networks more secure), we believe

that the core features of Honeynet technology, namelycontrolled isolation and exposure to artificialvulnerabilities, can be quite successfully used to actively

increase the security of networks when integrated into IDSmechanisms.

VII. REFERENCES[1] Stefan Axelsson :Intrusion Detection Systems: A

Survey and Taxonomy, Chalmers University of

Technology, Goeteborg, Sweden, 14 March 2000[2] Stuart Staniford: Containment of Scanning Worms in

Enterprise Networks, Silicon Defense, 7 Oct. 2003

[3] N.Weaver, V. Paxson, S.Staniford, R. Cunningham:

A Taxonomy of Computer Worms, Proceedings ofthe 2003 ACM workshop on Rapid Malcode,Washington, DC, USA

[4] The Honeynet-Project: ,Know Your Enemy:Learning about Security Threats'', Indianapolis:

Addison-Wesley, 2004, http://www.Honeynet.org/

[5] S. Riebach, B. Tdtmann, Erwin P. Rathgeb: ,Riskassessment of production networks using Honeynets -

some practical experience'', proceedings of ISPEC05conference, Singapore, 12.-14. April 2005

[6] Debar H., Dacier M., Wespi A.: ,,Towards a

Taxonomy of Intrusion-Detection Systems'', ComputerNetworks, 31(8): S. 805--822, April 1999

[7] Roesch, Marty; Caswell, Brian: ,Snort's official

homepage'', http://www.snort.org, 2. Feb. 2005

[8] Rami Lehti: AIDE official homepage:http://www.cs.tut.fi/~rammer/aide.html, 2005

[9] S. Riebach, B. Tdtmann, Erwin P. Rathgeb:

Efficient deployment of Honeynets for statistical andforensic analysis of attacks from the Internet'', proceedings for Networking 2005 conference,

Waterloo Ontario, Canada, 02.-06. May 2005

[10] Biles, S.: ,,The SPADE Project'', last seen: 11. Oct.2004, http://www.bleedingsnort.com/article.php?

story=20041011095505501[11] Zeltserman, D.: ,,A practical guide to SNMPv3 and

network management'', New Jersey 1999

[12] Decker E., Langille P., Rijsinghani A., McCloghrie

K.: ,,RFC 1493 - Definitions of Managed Objects forBridges'', Internet Standard, 1993

[13] IEEE: ,,Port-Based Network Access Control'', New

York 2001

[14] Blunk L., Vollbrecht J.: ,,RFC 2284 - PPP ExtensibleAuthentication Protocol (EAP)'', Internet Standard,

1998

[15] Metcalf, W.: ,,Snort\_inline Projekt Homepage'',http://snort-inline.sourceforge.net/, last seen: 2. Feb.

2005

[16] Allen, J., Christie, A., Fithen, W., McHugh, J., Pickel,J. and Stoner, E.: State of the Practice of IntrusionDetection Technologies'', CMU/SEI-99-TR-028

(2000)

[17] E., Cloete, E., Venter, L.M.: ,,A comparison of

Intrusion Detection systems'', Computers and Security,20 (2001), S. 676-683

[18] Lazarevic A., Ozgur A., Ertoz L., Srivastava J., KumarV.: ,,A comparative study of anomaly detection

schemes in network intrusion detection'', in: SIAMInternational Conference on Data Mining (2003)

[19] Kruegel, C., Toth, T., Kerer, C.: ,,Decentralized eventcorrelation for intrusion detection'',http://www.infosys.tuwien.ac.at/Staff/tt/publications/

Decentralized\_Event\_Correlation\_for\_Intrusion\_detection.pdf, April 2002

[20] LBNL's Network Research Group: ,,arpwatch'',

http://www-nrg.ee.lbl.gov/, last seen: 2. February2005

[21] Linux netfilter project: ,,netfilter/iptables'',http://www.netfilter.org/, last seen: 2. Febraury 2005

[22] Schuymer, Fedchik, Borowiak: ,,ebtables'',http://ebtables.sourceforge.net/, last seen: 2. February2005

[23] VMware, Inc.: ,,VMware Workstation 4'',http://www.vmware.com/, last seen: 2. February 2005


the honeynet quarantine

Documents