HONEYD DETECTION VIA ABNORMAL BEHAVIORS

GENERATED BY THE ARPD DAEMON

A. Boulaiche

ReSyd Doctoral School, University of Bejaia, Algeria

K. Adi

Computer Security Research Laboratory, University of Qubec in Outaouais, Canada

Keywords:

Security, Honeypot detection, Abnormal behaviours, ARP protocol.

Abstract:

In this paper we describe some serious ﬂaws in the software Honeyd that is one of the most popular software of

honeypots, these ﬂaws allow an attacker to easily identify the presence and the scope of a deployed honeypot.

Hence, we describe in details both the ﬂaws and how they can be used to attack the honeypot. Furthermore, we

elaborate a set of possible solutions to ﬁx each of these ﬂaws. Our technique is mainly based on the detection

of abnormal behaviors of the honeypot.

1 INTRODUCTION AND

RELATED WORK

Honeypots (Spitzner, 2002) have recently received a

lot of attention in the research community. They can

be used for several purposes; they can provide early

warning about new attacks, exploitation trends, at-

tack tools, and evolving attack techniques. Honey-

pots are more and more deployed within computer

networks. However,malicious attackers start to devise

techniques for detecting and circumscribing these se-

curity tools (Holz and Raynal, 2005), while the hon-

eypot deployments must remain hidden in order to be

useful. An attacker who is aware of the location of

a monitor can avoid it, mislead it by feeding it er-

roneous information, or even target the monitor it-

self. Honeyd (Provos, 2002; Provos, 2003; Provos,

2005) is one of the most popular solutions proposed

so far for honeypot technology. It is able to emulate

the behavior of most common IP-stack implementa-

tions. During its normal operation Honeyd listens on

the network interface card (NIC) for incoming ARP

requests. If an ARP request is detected, it initiates an

ARP request itself. If no response to the own ARP

request is given and a rule for the requested IP exists

in the conﬁguration ﬁle, Honeyd overtakes the IP and

starts pre-conﬁgured services on the speciﬁed ports.

Like any honeypot solution, the stealhtiness of a

deployed Honeyd is very important in order for the

later to work properly and to avoid exposing itself to

speciﬁc attacks. Indeed, honeyd can carry risks to a

network, and must be handled with care to avoid an

attacker to use them to break into a system. Unfortu-

nately, this stealthiness is not guaranteed as we will

show in this work. Hence, one of the most effective

methods to detect the honeypot is to analyze the con-

tent of various generated IP-packets and to compare

them afterwards with the content of the same types of

packets generated by a normal machine. This compar-

ison allows us to discover some abnormal behaviors

of the honeyd technology which leads to its detection.

Honeypots technologies have been extensively

studied during the last decade and many Honey-

pot solutions have been proposed. For instance,

the Honeynet Project (Provos, 2005) offers a height-

interaction honeypot system. It is composed by a

network of honeypots that are controlled by a set of

tools collected in the Honeywall gateway that acts as

a bridge between the Internet and the network of hon-

eypots. The Honeynet Project is used to gather in-

formation about tools, tactics, and intents involved in

computer and network attacks. Jiang and Xu (Jiang

and Xu, 2004) presented a virtual honeynet system

that has a distributed presence and a centralized op-

eration. Anagnostakis et al. (Anagnostakis et al.,

2005) proposed ”Shadow Honeypot”, a hybrid archi-

tecture that combines the best features of honeypots

Boulaiche A. and Adi K. (2008).

HONEYD DETECTION VIA ABNORMAL BEHAVIORS GENERATED BY THE ARPD DAEMON.

In Proceedings of the International Conference on Security and Cryptography, pages 65-71

DOI: 10.5220/0001927200650071

 SciTePress

and anomaly detection. Honeypots attacks and de-

tection techniques have also been studied. For in-

stance, Dornseif et al. (Dornseif et al., 2004) have

proposed an approach for attacking a honeynet lo-

cally. Krawetz (Krawetz, 2004) proposed a commer-

cial anti-honeypot spamming tool: ”Send-Safe’s Hon-

eypot Hunter”. The later attempts to detect ”safe”

proxies for use with bulk-mailing tools. Xinwen (Fu

et al., 2006) proposed a new technique that allows an

attacker to remotely ﬁngerprint Honeyd by measuring

the latency of the network links emulated by Honeyd.

The reminder of this paper is structured as fol-

lows: section 2 gives an overview about Honeyd tech-

nology, section 3 describes our experimentations and

the discovered ﬂows in the honeyd technology, sec-

tion 4 proposes some solutions for ﬁxing the discov-

ered ﬂaws. Finally, we provide in section 5 our con-

clusion.

2 HONEYD OVERVIEW

Honeyd is a popular open source low interaction hon-

eypot that runs on BSD, Linux and Solaris, although

recently ported to Windows. It offers a simple way to

emulate services offered by several machines on a sin-

gle one. The primary purpose of Honeyd is detection,

speciﬁcally to detect unauthorized activities within

your organization. It does this by monitoring all the

unused IP addresses in the network. Any attempt

connection to an unused IP address is assumed to be

unauthorized or malicious activity, so it generates an

alert. Recently, honeyd has been used for many pur-

poses. For exemple, it is used to detect,to analyze, and

to respond to attacks against organization networked

assets, regardless of where those threats come from.

Honeyd is generally used in conjunction with another

freely available utility called arpd (Song and Provos,

2003) that allows a single host to monitor multiple ad-

dresses on a network by responding to ARP requests

for unclaimed IP addresses.

Honeyd’s architecture consists of several compo-

nents: a conﬁguration database, a central packet dis-

patcher, a protocol handlers, a personality engine, and

an optional routing component. The conﬁguration

database is a sequence of templates, where each one

of them represents a system to be emulated. Inside

every template, we ﬁnd the personality of a system,

its uptime, its UserID, its GroupID, the state of its

ports, and the IP address associated to it. The central

packet dispatcher is used to put the outgoing packets

in TCP/IP packets, and analyze the received TCP/IP

packets according to the associated ﬁngerprint. The

personality engine is used by Honeyd for referring to

the network stack behavior of a virtual honeypot. The

daemon uses the Nmap ﬁngerprint list as a reference.

The conﬁgured services are script sets. Each script

emulates a service of a real system. When the Honeyd

daemon receives a packet for one of the virtual hon-

eypots, it is processed by a central packet dispatcher.

The dispatcher checks the length of the IP packet and

veriﬁes its checksum and then, it queries the conﬁgu-

ration database of a honeypot conﬁguration that corre-

sponds to the destination IP address. If no such con-

ﬁguration exists, the default template is used. Then

the dispatcher calls the protocol speciﬁc handler with

the received packet and the corresponding honeypot

conﬁguration. For ICMP, it answers with an ICMP

ECHO reply packet. For TCP and UDP, the daemon

can establish connections to arbitrary services that re-

ceive data on standard input system and send their

output to standard output system. For more details,

see (Provos, 2003).

3 HONEYD ANALYSIS

To make the distinction between the physical ma-

chines and the various virtual ones which are cre-

ated by honeyd, we classiﬁed them in three different

classes:

• Class 1: class of real physical machines,

• Class 2: class of virtual machines created by hon-

eyd corresponding to templates which are differ-

ent from the default one deﬁned in the conﬁgu-

ration ﬁle. In this class, the number of virtual

machines and their IP addresses are ﬁxed in the

conﬁguration ﬁle.

• Class 3: class of virtual machines created by hon-

eyd corresponding to the default template deﬁned

in the conﬁguration ﬁle. In this class, the number

of virtual machines is dynamic and their addresses

are based upon on the free addresses in the physi-

cal network.

Throughout this paper we will try to compare the ma-

chine behaviors of the last two classes with those of

the ﬁrst class, by trying to highlight some abnormal

behaviors. These can lead to the detection of the hon-

eyd technology.

In order to show the ﬂaws of the honeyd tech-

nology that allows an attacker to easily identify the

presence and scope of a deployed honeypot, we con-

ducted the following experiment. We used Honeyd

to setup three other virtual machines (honeypots) on

the local area network of our university. The ﬁrst

honeypot is a Linux Suse 8.0, the second honey-

pot is a Windows XP Professional SP1 Microsoft,

SECRYPT 2008 - International Conference on Security and Cryptography

and the last honeypot is a Windows 2000. Each

of these honeypots runs the services: HTTP, FTP,

SMTP, TELNET, Netbios-ns, Netbios-dgm,netbios-

ssn, Microsoft - ds. The IP addresses associated to

these three machines are successively: 172.16.12.13,

172.16.12.14, and 172.16.12.15. The rest of the range

addresses 172.16.12.0/24 ,which is free, is automati-

cally allocated to the third class machines deﬁned in

the default template.

3.1 First Experimentation

In the ﬁrst test, we captured the incoming and outgo-

ing ARP trafﬁc of our test machine by using the Ethe-

real (Lamping, 2004) packet sniffer, then we launched

three pings commands: the ﬁrst was intended towards

a real machine at 172.16.41.41, the second was in-

tended towards the machine 172.16.12.13 of the sec-

ond class and the third was intended towards the ma-

chine 172.16.12.1 of the third class. During the exe-

cution of these three pings, the ARP trafﬁc captured

by Ethereal is illustrated in Figures 1, 2 and 3.

Figure 1: ARP trafﬁc for the ﬁrst ping.

Figure 2: ARP trafﬁc for the second ping.

Figure 3: ARP trafﬁc for the third ping

In the three ﬁgures, the test machine broadcast

an ARP packet carrying the question ”who has

$IP ADDRESS (”who has 172.16.41.41” for the ﬁrst

ping, ”who has 172.16.12.13” for the second ping and

”who has 172.16.12.1” for the third ping) to obtain the

MAC address of the destination machine. Then the

machine that has this particular IP address answers by

an ARP packet containing its MAC address. For the

ﬁrst class machine and the one of the second class,

the answer is sent to the test machine which asked

this address (see the destination ﬁeld in the circle of

the two ﬁrst ﬁgures). On the other hand, for the third

class machine (default virtual machine), the answer is

broadcasted to every machine on the network (see the

destination ﬁeld in the circle of the last ﬁgure). This

broadcast is considered as an abnormal behavior of

the honeyd ARP protocol. By exploiting this ﬂaw, an

attacker who controls (locally or remotely) a machine

on the same LAN as the honeyd can easily detect the

presence of the honeyd and its controlled virtual ma-

chines.

To resolve this problem it is necessary to modify

the source code of the arpd daemon by canceling the

ARP answers broadcasting.

3.2 Second Experimentation

During the second test, we launched several ping

commands towards ﬁve machines of the third class

from the test machine 172.16.12.12. The ARP Traf-

ﬁc captured by Ethereal during the execution of these

ping commands are illustrated in Figure 4.

Figure 4: ARP trafﬁc for the pings commands series.

In this ﬁgure, we can notice the ﬂaws that can lead

to the detection of the presence and the scope of a

honeyd deployment:

• the ﬁrst discovered anomaly concerns the big

framed trafﬁc in the ﬁgure. In this trafﬁc, we can

see that every time the arpd daemon receives an

ARP request for a third class machine, it broad-

casts an identical request in order to determine if

there is a ﬁrst class machine with this IP address.

If it is not the case, it answers the ARP request

with the MAC address of the honeyd host. But

unfortunately, this behavior can be considered as

suspect by an attacker. The later can launch an

ARP scan towards all network machines and can

deduce addresses representing the honeyd accom-

modating machine.

• the second discovered anomaly concerns MAC

addresses of ARP answers. As shown in Figure

4 (see the small frames), all answered addresses

are identical. This comes from the default tem-

plate of the conﬁguration ﬁle concerning the Eth-

ernet card type of the third class machines. This

HONEYD DETECTION VIA ABNORMAL BEHAVIORS GENERATED BY THE ARPD DAEMON

means that all these various IP addresses have the

same MAC address which is an impossible situ-

ation in a real system. Such situation is suspect,

and offers the possibility for the attackers to iden-

tify the presence and scope of a deployed honey-

pot. The attacker can launch an ARP scan from a

machine on the same LAN as the honeyd which he

controls (locally or remotely) and extracts IP ad-

dresses having the same MAC address. These ad-

dresses represent the third class virtual machines

(virtual machines of the default template) man-

aged by honeyd.

3.3 Third Experimentation

In the third experimentation, we assigned the

172.16.41.41 address of a ﬁrst class machine (real

machine) to a machine of the second class created

by honeyd. Then we restarted honeyd, and ﬁnally

we launched a ping command toward the machine

(172.16.41.41). The ARP trafﬁc captured by Ethereal

during the execution of this ping command is illus-

trated in Figure 5.

Figure 5: ARP trafﬁc for the address conﬂict ﬂaw.

As shown in this ﬁgure, there is two different an-

swers for the ARP request corresponding to the

172.16.41.41 machine (see the frame in the ﬁgure).

The arpd daemon answered directly without conﬁrm-

ing if this address is already associated to another ma-

chine, since it considers that the addresses allocated

to the second class machines are manually veriﬁed by

the administrator. This situation will lead to a MAC

address conﬂict as shown in the ﬁgure. This conﬂict

can be easily discovered by attackers snifﬁng the net-

work.

4 PROPOSED SOLUTIONS

To remedy these discovered ﬂaws, we suggest en-

hancing the honeyd technology by four new modules

and modifying the arpd daemon to make it compatible

with these new modules. Each module will be used to

patch of one of these ﬂaws.

• Module for Allocated IP Addresses,

• MAC Address Translation Module,

• Virtual MAC addresses generator,

• IP Addresses Check Module.

The new general structure of the honeyd technology

after the integration of these four modules is shown in

Figure 6.

Figure 6: New general structure of the honeyd technology.

Hereafter, we describe in details the proposed mod-

ules.

4.1 Module for Allocated IP Addresses

This module is used to resolve the problem of collect-

ing information about free IP addresses belonging to

the address-interval controlled by the arpd daemon.

The current arpd implementation uses the technique

of broadcasting the received ARP requests, but as we

saw in our experimentation, this technique leads eas-

ily to the detection of the honeyd technology. Hence,

to solve this problem we have to introduce a new tech-

nique allowing us to obtain the free IP addresses list

without awakening attackers suspicions, either by us-

ing a passive technique, or by using active techniques

without broadcasts.

Indeed, when the LAN uses a DHCP server to al-

locate dynamically IP addresses to the various ma-

chines of the network, the best way to obtain the list

of allocated IP addresses is to get it from the DHCP

server, either passively by snifﬁng incoming and out-

going packets toward and from this server, or actively

by asking it periodically. And to ensure this operation

effectively, the honeyd host machine must be installed

on the same network segment as the DHCP server.

To show how it is possible to obtain the list of free

IP addresses by using the DHCP packets snifﬁng tech-

nique, we didthe following test:

We installed a DHCP server into a Linux

(RHEL4) machine, and from another Windows XP

machine we launched the Ethereal sniffer, then from

the Windows conﬁguration panel we indicated that

the network card must receive dynamically an IP ad-

dress.

The DHCP trafﬁc captured by Ethereal is shown

in the following ﬁgure (7):

SECRYPT 2008 - International Conference on Security and Cryptography

Figure 7: DHCP trafﬁc captured by Ethereal.

1. To obtain dynamically an IP address, the

Windows machine broadcast (general broadcast

”255.255.255.255”) a ”DHCP discover” packet to

research a DHCP server which will provide an IP

address to it. It uses the source address 0.0.0.0

because it has had no IP address yet.

2. The DHCP sever of the Linux machine, which has

the intention of offering the 172.16.0.9 IP address

to this client, broadcast an ARP request on this

address in order to see if it is available in the net-

work.

3. If the DHCP server does not receive an answer to

its ARP request, it offers this address to the client

by sending a ”DHCP Offer” to it.

4. The Windows machine answered to the DHCP

servers offer in order to conﬁrm the taking of the

IP address sent (because it can be taken by several

DHCP servers which answer, so there must be a

conﬁrmation to the server selected by the client).

5. The DHCP server answers by ”DHCP ACK” to

accept or acknowledge the new IP allocation.

6. 7. 8. The client (the Windows machine) do three

ARP broadcasts to verify from its side that the

172.16.0.9 IP address is not duplicated on the net-

work.

9. If he does not receive any answer for his ARP

broadcasts, he registers his new address.

Indeed, the validity duration of the IP address affected

by the DHCP server is limited by the duration deﬁned

in the conﬁguration ﬁle ”/etc/dhcp.conf (in our case

it is of 20 seconds). So, if the client stays connected

more than this deﬁnite duration, he must renew it pe-

riodically, by sending a ”DHCP request”, in order to

receive a ”DHCP ACK” from the DHCP server bear-

ing a new duration equals to the previous.

The information list carried in the ”DHCP Offer”

packets and the DHCP ACK packets are shown in the

following ﬁgure (8):

What interests us in all this information captured

is the agreement packets (DHCP ACK) sent by the

DHCP server, and privately: the given address (the

four bytes of the numbers: 16, 17, 18, and 19 of the

”DHCP ACK” packet) and the validity duration (the

six bytes of the numbers: 249, 250, 251, 252, 253,

254).

Figure 8: The information lease sent by the DHCP server.

So, our sniffer will be programmed to capture only

the DHCP ACK packets, in order to save into a text

ﬁle all allocated addresses with the validity duration

of each of them.

Besides saving this information, our sniffer test

periodically the content of a ﬁle to extract the list of

expired addresses. In order to send them test packets

to conﬁrm if they are still active or not. So the general

algorithm of our sniffer is:

MainProgram AllocIPAddMod

Var dhcp_server_ip : string;

allocated_addrs_file : TextFileObject;

Begin

BeginPARALLEL

Sniffer(eth0, dhcp_server_ip,

allocated_addrs_file);

PARALLEL

Expiry_test(allocated_addrs_file);

EndPARALLEL

End.

Procedure Sniffer(ethi, dhcp_server_ip,

allocated_addrs_file)

Var traf : StringObject ;

dhcp_pack : DHCPPacketObject ;

Begin

While true Do

Capture_traffic(ethi, traf);

If traf.Src_IP_addr()==dhcp_server_ip Then

dhcp_pack := traf.Extract_DHCP_packet();

If dhcp_pack.Type() == "DHCP ACK" Then

allocated_addrs_file.Insert(

dhcp_pack.Allocated_addr(),

dhcp_pack.Validity_duration());

EndIf

EndWhile

EndProcedure

Procedure Expiry_test(allocated_addrs_file)

Var expired_ip_list: StringListObject;

free_expired_ip_list : StringList ;

Begin

While true Do

Sleep(T);

expired_ip_list :=

allocated_addrs_file.Expired_ip();

free_expired_ip_list :=

expired_ip_list.Test_free_expired_ip();

allocated_addrs_file.Delete(

free_expired_ip_list);

EndWhile

EndProcedure

4.2 MAC Address Translation Module

This module ﬁxes the third ﬂaw. Its mechanism

is similar to the NAT technology (Network Address

Translation). This module contains a virtual MAC

address list generated by the MAC address genera-

tor module. Addresses are similar to MAC address

HONEYD DETECTION VIA ABNORMAL BEHAVIORS GENERATED BY THE ARPD DAEMON

supplied by VMWare (Website1, 2008). From this

list and the free address list supplied by the previous

module AllocIPAddCMod as well as addresses of the

conﬁguration ﬁle ”honeyd.conf”, it generates a corre-

spondence table where each entry corresponds to an

IP address of a virtual machine managed by honeyd

with the associated virtual MAC address. By using

this table, the arpd daemon will answer ARP requests

for virtual IP address by sending the corresponding

virtual MAC address. The proxy is conﬁgured to lis-

ten to the network in promiscuous mode, and as soon

as it receives a frame, it veriﬁes its destination MAC

address. If this address has an entry in the correspon-

dence table then the later is replaced by the MAC ad-

dress of the honeyd machine and the frame sent to

it. The frames generated by honeyd are sent at ﬁrst

towards the proxy. The later will change their MAC

source addresses by the virtual MAC addresses ac-

cording to IP source addresses of packets carried in

these frames, and sends them then toward their ﬁnal

destination. So the general algorithm of this module

is:

MainProgram MACAddTransMod

Import honeyd.conf, allocated_addrs_file,

virtual_MAC_addrs_file ;

Var corresp_table : ObjectTable; Begin

corresp_table.Initialization(honeyd.conf,

allocated_addrs_file,

virtual_MAC_addrs_file);

BeginPARALLEL

While true Do

Sleep(T);

corresp_table.Update(allocated_addrs_file,

virtual_MAC_addrs_file);

EndWhile

PARALLEL

Manage_traffic(corresp_table);

EndPARALLEL

End.

Procedure Manage_traffic(corresp_table)

Var traf : StringObject ;

Begin

BeginPARALLEL // Traffic intended

// towards honeyd.

While true Do

Capture_traffic(eth0, traf) ;

If Belong_to(traf.Dest_ip_addr(),

corresp_table) Then

traf.Change_dest_MAC_addr(

honeyd_MAC_add);

Send_to_honeyd(traf) ;

EndIf

EndWhile

PARALLEL // Outgoing traffic of honeyd.

While true Do

Receive_honeyd_outbound_traffic(traf);

MAC_Addr:=corresp_table.Extract_MAC_addr(

traf.Src_IP_addr());

traf.Change_src_MAC_addr(MAC_Addr);

Send_to_network(traf);

EndWhile

EndPARALLEL

EndProcedure

4.3 Virtual MAC Addresses Generator

As its name implies, this module is built to generate

a list of unused virtual MAC addresses in the hon-

eyds LAN.This list will then be used by the MAC

Addresses Translation Module to generate the corre-

spondence table.

Furthermore, the MAC addresses conﬂict arises

only in the local area networks (the sources and ad-

dressees machines have a direct physical link among

them), so the creation of the virtual MAC addresses

list is relatively easy. It is enough to generate in

a unpredictable way a big number of virtual MAC

addresses of various usual builders, and delete from

it afterward all the addresses already existing in our

physical local area network, by a simple comparison

with a ﬁle containing the list of all MAC addresses of

our physical local area network.

4.4 IP Addresses Check Module

This module is conceived to ﬁx the addresses conﬂict

problems like those noticed in the last experimenta-

tion. Every start up of honeyd, this module veriﬁes

the IP addresses allocated to the various templates in

the conﬁguration ﬁle in order to test if there is no real

machine which took one of these addresses, by using

the same technique used with the DHCP mechanism.

As soon as it discovers that one of these addresses is

already associated with another real machine, it shows

an error message to the administrator and does not

start until the issue is resolved. To facilitate the ad-

ministrator task, this mechanism must be able to look

for the free addresses in order to suggest them with

the message. So the general algorithm of this module

is:

MainProgram IPAddCheckMod

Import allocated_addrs_file, honeyd.conf;

Var honeypots_ip_list,

erreur_ip_list : ListObject;

Begin

honeypots_ip_list[] :=

Extract_ip(honeyd.conf);

For i=1 to honeypots_ip_list[].length() Do

If Allocated(honeypots_ip_list[i]) Then

erreur_ip_list.Insert(

honeypots_ip_list[i]);

EndIf

EndFor

If Not Empty(erreur_ip_list) Then

free_ip := Extract_free_ip(

allocated_addrs_file);

Alert_administrator(alert_msg,

erreur_ip_list);

Offer_to_administrator(free_ip);

EndIf

End.

4.5 Modiﬁed ARPD Daemon

As we said ﬁrst, the mechanism of arpd daemon is to-

tally changed. It is no more based on the send out

of its own broadcast ARP requests to be sure that

an IP address is truly unused before claiming it with

an ARP reply. It rather works in conjunction with

the correspondence table supplied by the ”MACAd-

dTransMod” module containing all the free IP ad-

dresses with the virtual MAC address. So, when it

SECRYPT 2008 - International Conference on Security and Cryptography

receives an ARP request for such an IP address, the

deamon veriﬁes directly in the correspondence table

if there is an entry for this address or not and if it

is the case, it extracts the virtual MAC address cor-

responding to this address from the correspondence

table, then it loads it in the answered packet and send

it to the requester. So, the general algorithm of the

arpd daemon is:

MainProgram ARPd

Import corresp_table ;

Begin

While true Do

Capture_ARP_Requests(eth0, arp_req);

If Belong_to(arp_req.ip_addr(),

corresp_table) Then

MAC_Addr:=

corresp_table.Extract_MAC_addr(

arp_req.ip_addr());

arp_rep := prepare_ARP_reply(MAC_Addr);

Send_reply(arp_rep, arp_req.src());

EndIf

EndWhile

End.

To our knowledge, there will be no possibility in

the future to exploit the ﬂaws discovered in this ar-

ticle with the implementation of those three modules

and their integration with the current honeyd technol-

ogy. This hardens honeyd defences against attacks

intended to detect honeypots.

5 CONCLUSIONS

In this paper, we have presented various techniques

that can be used by potential attackers to detect the

presence of any Honeyd-based honeypot. They can

subsequently modify their attack to either avoid the

honeypot or send misleading trafﬁc to the honeypot

to hide their actions. We have made different exper-

imental tests that allow us to highlight suspect be-

haviors of honeyd technology, and demonstrate how

an attacker can exploit easily these ﬂaws to detect

the presence of this technology. Furthermore, we

have presented some possible solutions to solve the-

ses problems.

So, with this work, we can say that the honeyd

technology really acquired more strength against de-

tection attacks. But naturally, the ﬂaws discovered in

this article are not the only ones. Therere certainly

other ﬂaws which awaits us to be discovered. Only

with hard work can we ﬁnd them before they are ex-

ploited by malicious hackers.

REFERENCES

Anagnostakis, K. G., Sidiroglou, S., Akritidis, P.,

Xinidis, K., Markatos, E., and Keromytis, A. D.

(2005). Detecting targeted attacks using shadow

honeypots. In SSYM’05: Proceedings of the 14th

conference on USENIX Security Symposium.

Dornseif, M., Holz, T., and Klein, C. (2004). Nose-

break – attacking honeynets. In Proceedings of

the 5th IEEE Information Assurance Workshop.

Fu, X., Yu, W., Cheng, D., Tan, X., Streff, K., and

Graham, S. (2006). On recognizing virtual hon-

eypots and countermeasures. DASC, IEEE Com-

puter Society.

Holz, T. and Raynal, F. (2005). Detecting honeypots

and other suspicious environments. In Systems,

Man and Cybernetics (SMC) Information Assur-

ance Workshop.

Jiang, X. and Xu, D. (2004). Collapsar: A vm-based

architecture for network attack detention center.

In Proceedings of 13th USENIX Security Sympo-

sium.

Krawetz, N. (2004). Anti-honeypot technology. IEEE

Security and Privacy, 2.1.

Lamping, U. (2004). Ethereal Developer’s Guide:

18189 for Ethereal 0.10.14. The Free Software

Foundation.

Provos, N. (2002). OpenBSD System Manager’s

Manual.

Provos, N. (2003). Honeyd : A virtual honeypot dae-

mon (extended abstract). In Security Workshop

in networking System, Hamburg.

Provos, N. (2005). Honeyd Project.

http://www.honeyd.org. Documentation

and tools for general ”honeyd” users.

Song, D. and Provos, N. (2003). arpd.

http://www.honeyd.org/tools.php. Docu-

mentation and tools for general ”honeyd”

users.

Spitzner, L. (2002). Honeypots: Tracking Hackers.

Addison-Wesley Longman Publishing, Boston.

Website1 (2008). Vmware homepage.

http://www.vmware.com. Documentation

and tools for general ”vmware” users.

HONEYD DETECTION VIA ABNORMAL BEHAVIORS GENERATED BY THE ARPD DAEMON