The Honeynet Quarantine: Reducing Collateral
Damage Caused by Early Intrusion Response
Birger Tödtmann, Stephan Riebach, Erwin P. Rathgeb
Computer Networking Technology Group
Institute for Experimental Mathematics
University of Duisburg-Essen, Germany
{btoedtmann,riebach,erwin.rathgeb}@iem.uni-due.de
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. INTRODUCTION
Over the last few years mobile computing and wireless
access 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 are
multiple, 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 the
internet 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 can
cause 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 alarm
generation 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 rule
based detection approaches (misuse detection) or they try to
detect deviations from normal operation, also known as
''anomaly detection'' [6]. While the first approach only
detects well known attacks based on predefined signatures,
the latter one is also able to detect previously unknown
attack patterns based on deviations from “normal” system
and network behavior. However, as “normal” behavior is
not fully defined – and may change dynamically – false
alarms (false positives) are generated at a certain,
sometimes significant, rate. This limits the usefulness of
Proceedings of the Sixth International Conference on Networking (ICN'07)
0-7695-2805-8/07 $20.00 © 2007
active, automated Intrusion Response Systems trying to
protect the network by e.g. shutting down suspicious
processes or disabling network connections on affected
systems. In case of a false positive IRSs will cause
“collateral damage” by impairing or even deactivating
“innocent” 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. An
IDS will typically rate this as viral or worm-like behavior
unless there is a specific rule set for Skype. Therefore, a
tightly configured IRS would deactivate this
communication or even disconnect the offending system
from the network.
To avoid these negative effects without sacrificing
detection sensitivity, we propose to combine intrusion
detection and response with mechanisms known from
Honeynets [4]. In our approach, suspicious systems are not
disconnected totally but automatically quarantined in a
special 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, the
restrictions for falsely suspected systems can be balanced
out with the risk generated for the network by quarantined
systems. Our proposed solution thus offers a differentiated
defense against rapid worm propagation inside local
networks.
In section II of this paper, this concept is introduced more
detailed. Section III presents a first prototype
implementation which demonstrates the feasibility of the
concept while section IV provides first results from lab tests
and measurements.
II. THE HONEYNET QUARANTINE
Typical production networks are not protected by
sophisticated HIDS installed on every workstation attached
to them – due to the effort that has to be spent and the
expertise 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
 network and it is necessary to identify and disconnect such
a system as soon as possible.
Our approach is to reliably identify compromised systems
by automatically connecting them to a Honeynet with its
sophisticated HIDS sensors – autonomous malware that
infects a Honeypot is far easier to detect than doing so in a
noisy production environment. However, this automated
investigation takes time. In order to provide the user of the
system with some basic service during the investigation but
at the same time shielding the production network from
further infection, our concept is to isolate a computer
system fast and automatically when an anomaly-based
NIDS 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 system
was falsely reported. When quarantined in such a way, the
Honeypots 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 the
user of the potentially compromised system are kept
tolerable 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 incident
report of an anomaly-based NIDS is used to trigger an
isolation procedure that partly removes the offending
system from the production network, still allowing
harmless, preconfigured traffic back into it while diverting
all other traffic to the quarantine network. The second part
is to expose (one or more) Honeypots that have been
configured like a typical production system – and are thus
vulnerable to the same exploits – directly to the suspected
machine. If one of the Honeypots is then being
compromised successfully, its HIDS will report it and the
isolation procedure is triggered again, this time to entirely
remove the compromised system from the network. If, on
the other hand, no further attack attempts are being reported
from the Honeypots, the isolated system is released back
into the production network.
A. Central monitor and investigation system
We 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 point
mapper and a configuration function to isolate, disconnect
or rehabilitate systems in the production network.
Furthermore, it connects to a Honeynet where quarantined
systems are moved into. This could even be implemented
on the monitor and investigation system itself by using
virtualization software such as VMware [23].
B. Anomaly detection sensor with two thresholds
A commonly used scheme for anomaly based intrusion
detection is to measure the relative frequency by which a
specific activity x occurs and use it as an estimate for the
1
The principle of isolation and verification of an initial suspicion is also
well known from controlling epidemics and identifying criminals, where it
is quite successfully applied.
Proceedings of the Sixth International Conference on Networking (ICN'07)
0-7695-2805-8/07 $20.00 © 2007
probability P(x) of its occurrence. After these
measurements, 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, a
definition of a threshold by the IDS administrator is
necessary – this threshold is consequently also responsible
for the rate of false positives and false negatives.. In order
to allow for a more sophisticated, two-phased intrusion
detection scheme as outlined above, we modify the
anomaly 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 and
upper threshold, further observation in the quarantine
network is initiated.
ƒ Alarm: Anomaly indicator above upper threshold,
event is definitely rated as dangerous; countermeasures
(e.g. shutdown of the switch port) are immediately
initiated.
C. Attachment point map
To 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 Ethernet
networks. VLANs can be maintained in complex,
hierarchical switched-LAN topologies if IEEE standard
802.1q is applied. Now, as a prerequisite for rapid isolation
using VLANs, the switch port to which the suspicious
system is attached has to be identified. We do this by
utilizing 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 resulting
data takes some time, we use a proactive approach where
all systems are mapped from their respective IP and MAC
addresses to ports when the initially connect to the
network.2
D. Isolation and rehabilitation
As mentioned before, we put suspicious systems into
quarantine by moving them into a special preconfigured
quarantine VLAN. A prerequisite is that all switches are
IEEE 802.1q enabled, i.e. the switches are able to recognize
the VLAN tags and will process them accordingly. The
quarantine VLAN ensures that all data packets from an
isolated system are tagged accordingly and are forwarded
based on these VLAN tags to the central monitoring
system. From there they are relayed either to the quarantine
network or the production network, depending on
preconfigured forwarding and filtering rules.
2
In case several systems are connected to the same port via a hub, the
whole segment attached to the port is isolated if necessary. If
authentication 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.
 Depending on the result of the investigations carried out
during the confinement, the isolation/rehabilitation function
is instructed to either finally disconnect the suspicious
system completely from the production network by shutting
down the physical switch port, or to reconnect it to the
production network by moving it to back the default
VLAN.
E. User-friendly traffic switch
As a result, we have established three distinct network
partitions which are connected to the central monitoring
system: The production network (default VLAN), a
segment which contains suspicious systems separated from
the production network (quarantine VLAN) and the
Honeynet.
A filter logic within the monitoring system now defines
how the packets are forwarded in a user-friendly, but
protective 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 is
allowed back into the production network
ƒ All other (potentially dangerous) traffic generated by the
suspicious system is diverted to the Honeynet
ƒ Traffic from both production network and Honeynet
destined to the suspicious system is delivered there
ƒ All traffic between the production network and the
Honeynet is blocked.
In such a scenario, a basic service can be provided to the
isolated system during the quarantine period. The potential
risk for the production network emanating from the
applications 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 the
monitored traffic in such a way that specific attack patterns
are normalized.3
F. Quarantine investigation
The quarantine VLAN is, through the rules described
above, directly connected to the Honeynet, where the
Honeypots represent typical systems similar to those found
in the production network. This reflects the actual threat
level for the production network.
Due to their HIDS sensors which can safely report almost
any activity going beyond the usual internal system
maintenance as an intrusion, the Honeypots are able to
verify the intrusion of the suspicious system quickly and
reliably (as it is the only source of an attack) and will report
it to the central monitoring system. It is crucial for the
effectiveness of the overall concept here that the HIDS
should operate with a low latency, i.e. rather than only
performing periodic checks of MD5 checksums [8], tighter
monitoring of local process activity, disk and (system) file
access is necessary. These techniques provide the
3
This makes sense especially if email is still allowed, to avoid spreading
of viruses that use this as transport mechanism.
Proceedings of the Sixth International Conference on Networking (ICN'07)
0-7695-2805-8/07 $20.00 © 2007
quarantine network and its Honeypots with examination
and observation capabilities way beyond those feasible in
the production network. Compromised Honeypots should
be automatically restarted with a clean configuration once
the isolated system has been removed from the Honeynet.
G. Quarantine timer
The partial isolation of suspicious systems is controlled by
a timer which is preconfigured by the network administrator
to balance out the detection accuracy and the restrictions
imposed on the isolated systems. If no attack activities are
detected on the Honeypots during this time period, it is
assumed that the suspicion was unsubstantiated. The system
is moved back to the production network in this case and,
thus, fully rehabilitated.
III. PROTOTYPE IMPLEMENTATION
Whereas the conceptual approach is quite straight-forward,
the technical details are more complicated, as first lab trials
demonstrate. In order to show the feasibility of the ideas
that have been outlined above, we set up a small test
scenario. There, we attached a first prototype of our
monitoring system and conducted several tests that
demonstrate that the basic functionality is available and also
yielded measurements on the performance of the solution.
We used Cisco switch equipment to provide the link layer
network infrastructure, WindowsXP systems for the clients
and a Linux system as central monitoring and investigation
system for IDS, rapid isolation and Honeynet quarantine.
As illustrated by Figure 1, the production Ethernet network
is in VLAN 2,4 whereas the quarantine VLAN has been
given the ID 3.
suspicious
quarantine
network system
monitor & (VLAN3)
investigation
system
(bridge) trunk
production
honeypot network
trunk
(VMware) (VLAN2)
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 also
attached 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 this
VLAN is the monitoring system itself.
4
The reason to use VLAN id 2 instead of the default VLAN (untagged) is
that Linux is not able to bridge between a non-VLAN interface and a
VLAN pseudo-interface if it has the non-VLAN interface as physical
parent.
 A. Snort/Spade configuration
As NIDS to look out for anomalies occurring within the
network we used the toolset Snort/Spade. Spade is an
anomaly-based detection plugin for Snort that can be given
an anomaly score threshold and will report an incident if it
observes network activity whose anomaly score exceeds
this threshold [10]. For the first prototype, we did not
enhance the Spade engine to offer a two-threshold reporting
scheme but simply used it with one threshold set at its
default value. Thus we had no upper bound which could
indicate a “definite incident” but had rather a huge margin
of suspicion (the other threshold then being, by definition,
infinite).5 The Snort process was then set up to report
incidents via the syslog mechanism available in Linux,
which in turn was configured to deliver alert messages from
Snort to a named pipe “/hq/snortreport” to which our
monitoring 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 activated
systems within the network [20]. When arpwatch sees a
new station, we call a script “mac2port” (this is done by
using 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 been
attached, by use of SNMP requests to all switches.6 At
worst 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 <MAC-Addr>:<Switch-
IP>:<ifIndex> in a file with the IP address of the system as
filename for later use by the isolation/rehabilitation
function:7
eth0.2 Ö arpwatch Ö mac2port Ö /hq/<ipaddr>
C. Isolation/rehabilitation control with SNMP
When Snort/Spade flags a suspicious system, our control
procedure can thus look up the switch and the port of the
offender and move the system into the quarantine VLAN by
sending a SNMPv3 “set” request to the switch which
contains vmVlan.<ifIndex> as OID and the new VLAN id
“3” 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 two
Snort/Spade processes with differing threshold configuration: if only one
of them reports an incident, the “suspicious” area is flagged.
6
This is accomplished by issuing three SNMPv3 requests obtaining OIDs
from the Bridge- and Interface-MIBs: the dot1dTpFdbPort.<MAC-Addr> OID
will 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.<Bridge-Port> and by reading vmVlan.<ifIndex>
from Cisco’s VLAN-MEMBETSHIP-MIB we can assess whether the
found port is a trunk port (which is then not the attachment point because it
will never be on a trunk).
7
This procedure will have to be refined in the future as spoofing IP and
MAC addresses by an attacker may currently result in huge file system
bloat.
Proceedings of the Sixth International Conference on Networking (ICN'07)
0-7695-2805-8/07 $20.00 © 2007
MAC table of the switch.8 The performance of this
operation depends on the speed of the network and is
usually completed within a second as it takes almost no
time at the switch.
qtimer
×
/hq/snortreport Ö honidsctl Ö snmpset
×
/hq/<ipaddr>
We thus ensured that upon Snort issuing the first alert
(under slight network load this is done between 1-2 seconds
after observing the suspicious activity), our mechanism
isolated the corresponding system very fast and efficiently.
Furthermore, the control program fires up a timer
(“qtimer”) that will trigger the rehabilitation function after
20 minutes by using a named pipe called “notguilty”:
qtimer Ö /hq/notguilty Ö honidsctl Ö snmpset
The control program will then, with similar SNMP
messages as used for isolation, move the port back into
VLAN 2. A third named pipe, called “guilty”, will inform
the control program to shut down the offending system in
case 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 setup
Whereas a full-fledged, non-virtualized Honeynet may have
its benefits, we decided to use a simple VMware Honeypot
for 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 investigations
on the inner workings of a caught virus. We thus used
VMware’s methods to make the working disk of the guest
system non-persistent, which means that changes to the disk
image 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 a
compromised Honeypot very easily (by simply rebooting it
from the original, write-protected image file), it also made
finding unauthorized file access much faster because only
the 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 FAT32
filesystem because the NTFS filesystem is not very suitable
for finding differences. In fact VMware writes single
sectors that have been changed by the guest to the REDO
file, thus it contains not a filesystem but only small parts of
it. 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 in
different VLANs because they don’t maintain separate MAC address
tables per VLAN. This has to be considered when building such a link
layer based isolation system.
 implemented this by periodically making a copy of the
REDO file and letting the utility xdelta compare both files
after 10 seconds:
/hq/vmpot.vmdk-s001.REDO_7JhTOS.10s-ago
Ø traffic
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 (our
Linux system) was able to detect several different virus
infections by observing new .DLL and .EXE files written to
the REDO log via the simple grep utility.
E. Bridge and filter configuration
In order to transparently forward traffic on the link layer
between 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 br0
using the brctl program. 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 that
only DNS, WWW and SMB traffic is allowed to pass from
eth0.3 to eth0.2, thus leaving the quarantine network and
entering the production network:
# allow arp
ebtables -t nat -A PREROUTING -j ACCEPT --in-if eth0.3 --protocol
arp --arp-opcode Request
ebtables -t nat -A PREROUTING -j ACCEPT --in-if eth0.3 --protocol
arp --arp-opcode Reply
suspicious
system
monitor &
investigation
system
(bridge)
production
honeypot network
(VMware) ARP requests (VLAN2)
and replies
Fig. 2: Step 1 - bridge ARP packets transparently to
enable MAC address lookup
This allows all systems to look up each others MAC
address transparently without further interference. When in
the next step the suspicious system wants to connect to a
production system, our traffic switch differentiates between
harmless traffic and all other redirected to the Honeypot (as
illustrated by Figures 2 and 3):
# allow certain production services (dns, shares, web) to be
reached
ebtables -t nat -A PREROUTING -j ACCEPT --in-if eth0.3 --protocol
ip --ip-destination 0.0.0.0 --ip-protocol 17 --ip-destination-port
53
iptables -t nat -A PREROUTING -j ACCEPT -m physdev --physdev-in
eth0.3 --destination 0.0.0.0 --protocol udp --destination-port 53
ebtables -t nat -A PREROUTING -j ACCEPT --in-if eth0.3 --protocol
ip --ip-destination 0.0.0.0 --ip-protocol 6 --ip-destination-port
139
iptables -t nat -A PREROUTING -j ACCEPT -m physdev --physdev-in
eth0.3 --destination 0.0.0.0 --protocol tcp --destination-port 139
ebtables -t nat -A PREROUTING -j ACCEPT --in-if eth0.3 --protocol
ip --ip-destination 0.0.0.0 --ip-protocol 6 --ip-destination-port
80
iptables -t nat -A PREROUTING -j ACCEPT -m physdev --physdev-in
eth0.3 --destination 0.0.0.0 --protocol tcp --destination-port 80
Proceedings of the Sixth International Conference on Networking (ICN'07)
0-7695-2805-8/07 $20.00 © 2007
suspicious
system
harmless
production
network
honeypot
(VMware) monitor & (VLAN2)
investigation
system
(bridge)
Fig. 3: Step 2a – bridge harmless traffic to production
network (VLAN2)
The redirection of traffic towards the Honeypot has to be
done in a bit more sophisticated way as we need to
exchange the destination IP and MAC addresses of packets
coming from the suspicious system to be forwarded to the
Honeypot system with IP address 10.0.0.1 and MAC
address 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-in
eth0.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 of
the Honeypot all the time. On the other hand, when the
Honeypot 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 reinstated
as the Linux’ netfilter system currently does not support
connection tracking on the link layer. This will not affect
the applications running on the systems but may serve
malicious code to detect our detour to the Honeypot.
suspicious
system
monitor &
investigation
system
(bridge)
production
honeypot network
(VMware) (VLAN2)
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 drop
all 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 set
up when the enhanced monitoring system boots up, together
with Snort and the VMware guest system that is also
automatically started.
 IV. EVALUATION
In first tests we were able to validate the basic functionality
which served the user reduced but tolerable access when
being quarantined after firing up Skype. As Skype was
started 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 were
thus able to react within at least 5 seconds to shield the
production network from further activity of a suspicious
system.9 However, the client was still able to successfully
access shares on a file server as well as webpages from the
Internet. As the periodically executed xdelta and grep did
not report newly created .DLL and .EXE files within the
disk of the VMware Honeypot, the “honidsctl” program
moved the system back into the production network after 20
minutes.
We then set up a client system that contained an active
Lovesan.A virus and connected it to our test network. Snort
this time also detected the infection attempts of the virus
and the corresponding system was isolated from the
production network. As the virus continued its spreading
attempts, we could observe the creation of the file
“MSBLAST.EXE” within the REDO file of the VMware
guest. Consequently, the compromise had been confirmed
and the client was entirely disconnected by “honidsctl” via
SNMP, administratively shutting down its access port. This
was a successful proof that an unconfirmed anomaly
observed in a noisy environment could be investigated more
thoroughly in a controlled, clean environment while at the
same time not impairing the usability too much.
A. Timing considerations
To find a lower bound for the performance of the system
that has to be reached in order to reliably contain viral
spread, we measured the time a typical worm needs to
infect another system. Therefore we placed two non-
persistent VMware guests (Windows XP) in a LAN and
started different internet worms on one of them. To cope
with the fact that most worms attack randomly generated
addresses we used DNAT to directly forward attack packets
to the victim host, not depending on the actual destination
IP address the virus calculated. We activated different
internet worms with some variants10 and monitored their
behavior with a packet tracing program. By measuring the
time 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 as
Snort 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 well
known as a virus repository.
Proceedings of the Sixth International Conference on Networking (ICN'07)
0-7695-2805-8/07 $20.00 © 2007
Sasser.A 5 sec. 4 6
Sasser.B 9 sec. 8 7
Welchia
After activation all variants were
A,E,G,H
inactive for at least 5 minutes
Randex.I
Table 1: Spreading time of well-known worms
This indicates that if a virus were to target an adjacent
system in the same network, a response system aimed at
effectively quarantining the virus’ host must do so in at
least 4-5 seconds. Our prototype currently suggests that this
may be achievable, especially when the network is not
loaded as this affects Snort performance. Note that viruses
right now do not target systems in the same network but
rather spread randomly, which gives a quarantining
function 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 to
time, 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 isolation
system.
B. Limitations
Currently our prototype is supporting one broadcast domain
as VLANs cannot spread beyond a subnet. The VLAN
switching with SNMP is working, but this confines the
solution to special switch equipment offering VLAN-
specific MIBs. Furthermore, the anomaly detection within
the VMware host is still sketchy, from time to time, the
.EXE and .DLL extensions of newly created files could not
be found in the REDO file reliably (maybe because the file
name resides in more than one disk sector). The HIDS also
is solely based on manipulations happening in the
Honeypot’s filesystem, a process monitoring mechanism
would be suitable as well.
Our control procedure currently supports the isolation and
investigation of only one suspicious system at a time.
Multiple incident handling while maintaining the Honeynet
functionality of a controlled, clean environment is non-
trivial, as for each suspicious activity separate VLANs and
Honeypots 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 (but
harmless) applications frequently, quarantine and
rehabilitation 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 WORK
As 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 issues
outlined above. Namely a notification mechanism for the
users will be integrated into the system as they can help to
increase the detection quality quite significantly – only
 users can observe the causal connection between their
activity and the quarantining process: “Whenever I click on
this icon, I get a message saying that my system is now
quarantined and I will only be allowed to access the internal
web pages”. Further working items are to stretch the
isolation procedure over subnet boundaries by using
techniques such as L2TP or Ethernet over MPLS, and the
implementation of investigative “threads” enabling multiple
incident handling.
VI. CONCLUSIONS
In this paper we have demonstrated a way to improve LAN
security, especially to contain the spreading of worms, by
implementing an enhanced two-phased anomaly-based
intrusion 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 is
undertaken. This has the potential to increase both
acceptance for IDS deployment and detection accuracy.
While the IDS and Honeynet communities are still
somewhat disjoint because of the diverging areas of interest
of those groups (Honeynets are still mainly used for
forensics and hacker behavior studies whereas IDS/IRS are
used to actively make networks more secure), we believe
that the core features of Honeynet technology, namely
controlled isolation and exposure to artificial
vulnerabilities, can be quite successfully used to actively
increase the security of networks when integrated into IDS
mechanisms.
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 of
the 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. Tödtmann, Erwin P. Rathgeb: ,”Risk
assessment of production networks using Honeynets -
some practical experience'', proceedings of ISPEC05
conference, Singapore, 12.-14. April 2005
[6] Debar H., Dacier M., Wespi A.: ,,Towards a
Taxonomy of Intrusion-Detection Systems'', Computer
Networks, 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
Proceedings of the Sixth International Conference on Networking (ICN'07)
0-7695-2805-8/07 $20.00 © 2007
[9] S. Riebach, B. Tödtmann, Erwin P. Rathgeb:
”Efficient deployment of Honeynets for statistical and
forensic 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 for
Bridges'', Internet Standard, 1993
[13] IEEE: ,,Port-Based Network Access Control'', New
York 2001
[14] Blunk L., Vollbrecht J.: ,,RFC 2284 - PPP Extensible
Authentication 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 Intrusion
Detection 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., Kumar
V.: ,,A comparative study of anomaly detection
schemes in network intrusion detection'', in: SIAM
International Conference on Data Mining (2003)
[19] Kruegel, C., Toth, T., Kerer, C.: ,,Decentralized event
correlation for intrusion detection'',
http://www.infosys.tuwien.ac.at/Staff/tt/publications/
Decentralized\_Event\_Correlation\_for\_Intrusion\_d
etection.pdf, April 2002
[20] LBNL's Network Research Group: ,,arpwatch'',
http://www-nrg.ee.lbl.gov/, last seen: 2. February
2005
[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. February
2005
[23] VMware, Inc.: ,,VMware Workstation 4'',
http://www.vmware.com/, last seen: 2. February 2005