Proceedings of the International Conference on Computer and Communication Engineering 2008
Countermeasure for Detection of Honeypot Deployment
Lai-Ming Shiue1, Shang-Juh Kao2
1
Department of Applied Mathematics
2
Department of Computer Science and Engineering
National Chung-Hsing University, Taiwan
Email: lmshiue@amath.nchu.edu.tw
Abstract
In this paper, a deceptive system, called
honeyanole, is developed to escape from honeypot
hunting as well as to collect attacking information. In
honeyanole, three phases of collection, redirection and
deception are implemented. In the collection phase,
four types of attacking information are gathered for
cross analysis to build up the blacklist. Upon the
blacklist being developed, two redirection techniques,
layer-2 and layer-3 redirection, are employed to
dynamically transmit incoming traffic to a production
or a deception server in the redirection phase. Finally,
the deception server could transparently capture the
attacking behaviors in the deception phase. With
honeyanole, we can effectively prevent honeypot
deployment from hunting, build an early warning
system, and enhance the system defense.
I. INTRODUCTION
As threats to network security increase with the
exponential growth, the traditional defensive systems,
such as firewall and intrusion detection systems, is
insufficient. Honeypots [1-4], a deceptive approach,
are introduced to trap hackers. Without being noticed
by hackers, attacking information is gathered and
analyzed in order to trace attacking behaviors. There
are two approaches to classify honeypots [5-7],
depending upon either the deployment purpose or the
interactions with the honeypot. Regarding with the
purpose of deployment, a honeypot could be
constructed for the production or research purpose.
Based on the interactions with the honeypot, a
honeypot could be either low-interaction or high-
interaction. No matter how a honeypot is classified,
either by purpose or by interaction, only when the
deployment is transparent, honeypot approach is
useful.
978-1-4244-1692-9/08/$25.00 ©2008 IEEE
May 13-15, 2008 Kuala Lumpur, Malaysia
Since the essential task of the honeypot strategy is
to make indistinguishable to attackers between a
deceptive system and a regular host, how to not expose
the honeypot deployment becomes critical. In general,
deception detection [8] could be service support
detection, connection feature detection, or system level
detection. Service support detection [9, 10] launches
all kinds of service requests to check for a honeypot.
Usually, an emulated service can be easily examined as
a deceptive system.
Connection feature detection [10] refers to remotely
test a target host and collect the transmission features,
such as latency, error, and protocol header. Through
the connection features analysis, a fabricated operating
system or a virtual network interface can easily be
discovered. For instance, a high detection rate of
recognizing a low-interaction honeypot was reported in
[11] by using Neyman-Pearson decision theory to
analyze information collected from round trip time of
icmp and tcp connections. And, Mukkamala et al [9]
demonstrated that high detection accuracy (higher than
95%) can be derived in identifying a honeypot by
using SVMs to analyze 49 various features of tcp
connections.
System level features, such as type of physical
devices, type of file systems, and the memory usage of
hidden programs, are required to detect [12, 13] a
high-interaction honeypot, no matter the real system is
deployed at a physical or virtual machine. There
already exists some collection tool for high-interaction
honeypots, for instance the Sebek [14], which works in
the kernel module to monitor system call invocations
and record data of interest. In [15], the NoSEBrEak
project has shown that Sebek can be detected and
disabled. Briefly, the three deception detection
techniques for discovering different types of honeypot
systems can be listed as in Table 1.
595

TABLE I. DETECTABILITY OF DECEPTION DETECTION METHODS
Interactio Detection Method
n
Machine
Type Connection Service
Level
Feature Support
low virtual detectable detectable
virtual detectable undetectable
high
physical undetectable undetectable
While the development of a honeypot system
focuses on the integration and analysis of attacking
information, the exposure of honeypot deployment will
make the deceptive system to be invalid. A common
countermeasure against the deployment exposure is to
redirect the connection to avoid directly interacting
with a honeypot. The redirection technique is to
decompose Internet traffic into two destinations: a
production server or a honeypot.
In general, the direction of traffic flows is decided
upon the intrusion detection engine. In [16], a bait &
switch honeypot router is constructed at the network
layer and uses network address translation (NAT) to
dispatch the traffic flows. However, such a pure layer-
3 redirection could easily slow down non-attacking
service connections and the deployment could be
revealed via the latency trace, such as via the icmp
protocol. In [17], a redirection module in honeypot
system at the data link layer is presented to lure
suspicious traffic into a honeypot system via changing
the MAC address. Unfortunately, when the layer-2
redirection is implemented in a connection oriented
network, the sequence number failure due to the re-
connection operation makes the honeypot system to be
suspicious.
In this paper, a deceptive system, called honeyanole,
is developed to escape from honeypot hunters as well
as to collect attacking information to enhance further
defense. In this system, non-attacking service
connections and probing connections are monitored
and transmitted, while the attacking service
connections are transparently redirected to the
fabricated system for the attacking process collection.
Finally, the system implementation and its evaluation
are reported.
II. THE HONEYANOLE SYSTEM
In honeyanole, both layer-2 and layer-3
redirection mechanisms are employed to dynamically
transmit incoming traffic flows for the purpose of
resisting the detection of honeypot hunters as well as
collecting and analyzing attacking information. We
categorize network connections into regular service
requests, probe requests, and attacking service
requests. Under the layer-2 redirection, regular service
connections and probe requests are directed to the real
System system. In this case, the redirection latency is
Level
insignificant, and hence the honeypot is not suspicious
undetectabl
to honeypot hunters. Once an attacking service
e
detectable connection is discovered, layer-3 redirection is active
and the connection is redirected to the fabricated
detectable
system.
There are three phases in honeyanole: collection
phase, redirection phase, and deception phase. The
main task of collection phase is to build a blacklist of
possible attackers to support the redirection server. As
shown in Figure 1, all traffic flows from Internet to
production server will be mirrored to the detection
module for intrusion inspecting. The information of
possible attackers will be gathered by collection
module from detection module and other three
defensive systems, including the illegal access log, the
record of probes, and exchanged defensive
information.
Mirrored Traffic
Detection redirection server
Module
Collection Analysis Decision
attacking information Module Module Module
from other systems
Figure 1. Modules inside the collection phase.
After the collection, the alerts of attacking
information for eliminating the same attack and
incurring a new threat based on alert type, source
address, and target address are raised. Then, the
analysis module performs the correlation of collected
attacking information to predefine attack scenarios,
such as network scans, port scans, or vulnerability
attacks. Upon finishing the analysis, the decision
module would build an orderly list of possible
attackers according to temporal information and
involved services. Finally, a blacklist is distributed to
redirection server dynamically.
For redirection, the server with external, internal,
and redirection interfaces are designated to connect to
Internet, a production network, and a deception server
respectively. When an incoming traffic arrives from
Internet interface, redirection module will transmit it to
a production server or a deception server with the aid
of the blacklist. Operational flows of the redirection
module can be depicted in Figure 2.
596
 Three deception programs, honeyd [20], honeytrap[21]
and linux with sebek [14], are deployed as deception
servers.
5HFHLYHIURP 6HQGRXWYLD
([WHUQDO,QWHUIDFH ([WHUQDO,QWHUIDFH In order to validate the feasibility of the
honeyanole, several tests in the test environments of
direct, bait & switch, and honeyanole were conducted
$SSHDULQ
%ODFNOLVW"
<HV 7DUJHW0DVTXHUDGH 6RXUFH0DVTXHUDGH as shown in Figure 4. Apache web server was
employed as the production server and Microsoft web
1R
/D\HU)RUZDUGLQJ 77/0DVTXHUDGH application stress tool was adopted to generate http
connections from the traffic generator.
/D\HU)RUZDUGLQJ /D\HU)RUZDUGLQJ 77/0DVTXHUDGH /D\HU)RUZDUGLQJ

5HFHLYHIURP 6HQGRXWYLD 6HQGRXWYLD 5HFHLYHIURP

,QWHUQDO,QWHUIDFH ,QWHUQDO,QWHUIDFH 5HGLUHFWLRQ,QWHUIDFH 5HGLUHFWLRQ,QWHUIDFH
Deception Report Agent
Agent
Production
Report Agent Server
Figure 2. Operation flows of redirection module.

If an incoming traffic is a probe or its source

Redirection Server
address does not appear in the blacklist, the layer-2
redirection would forward the traffic to a production Traffic Black List
Redirection
Module
Deception
Server
server via the internal interface without changing any Report Agent

packet’s content. However, if an incoming traffic has

its source address appearing in the blacklist, the layer- Detection
Module
Decision
Module
3 redirection will take place. With layer-3 redirection,
target masquerade changes the target address of Defensive
System
incoming packets into the deception server before defensive information exchange
Collection
Module
Analysis
Module

layer-3 forwarding. And, TTL masquerade adjusts the Collection Server

value of ttl in IP header to conceal from the action of
layer-3 forwarding. Similarly, the outgoing packets Figure 3. The global view of honeyanole.
will be adjusted accordingly.
The deception phase is responsible to capture the
intrusive processes. With honeyanole, various types of
honeypots systems can be deployed as deception
servers. Adopting a high-interaction honeypot can +XQWHU 5RXWHU
6ZLWFK
obtain more intrusive information and easily suffer
from deployment disclosure by system level detections,
while a low-interaction honeypot could be discovered 3URGXFWLRQ6HUYHU
by service support detections.
How to precisely predict an intrusion, more %DLW 6ZLWFK
%DLW 6ZLWFK 7UDIILF*HQHUDWRU
specifically honeypot detection, is the key feature to 'HFHSWLRQ6HUYHU 5RXWHU

deception detection. By combining the above three

phases, honeyanole system is built as shown in Figure
3. Therefore, how to build an effective and accurate +RQH\DQROH 3URGXFWLRQ6HUYHU

blacklist is an imperative task. All traffic to production 3URGXFWLRQ6HUYHU +RQH\DQROH

5HGLUHFWRU 'HFHSWLRQ6HUYHU 'LUHFW

server, including service connections and attacks, are

mirrored to detection module to execute an intrusive 'HFHSWLRQ6HUYHU
inspection. The alert generated by the detection
module is also the main part of attacking information. Figure 4. Test case network layout.

III. SYSTEM EVALUATION A. Connection Latency Test

Following the honeyahole architecture, we carried As for examining connection delay generated by
out the implementation in slackware linux both layer-2 and layer-3 redirections, the first test is to
environment. Iptables [18] and snort [19] are employed measure the connection latency in various situations.
as the redirection and detection modules respectively.

597
     
       
      
 
 

‡
  

     

 
 
        
 
     
<


 


    
   
  
    
               
      
      !" 
     
#'
'  
$! #%  # 

 

 

  
*++      
      
 
             


; <
 = <  

   
 




   


 

'
 
 
 

 < <
|<
  


  

            
      G`^<<


 

          
 
     <@"" 

   

 

  
  >  
‡
    #'    … 
  
 

<>#?@GQQ?@<GQ#><?Q@X?<??Q>Z\Q<?^>Q_<Z??`?^{?^ <>#?{@GQQ?@<GQŠ?><\^?>Q_`X`<?‹#?{?#_?<?@<GQ<?`<`

 

     '( $ % &



  !  !  !
  "#& #'() 
 
 

 "  "  "

 +=| }* +~~ }= +} =€ *#'#(+ ) 
 
 



 +*} =| +|~ € += ~
 +~ =| +‚+ =+ +€ =€
$ /0 #& #'"45) 
 
 



 +* ~ +~* | +=‚ ~~
6#+ #& # 
 
 

 |+ ‚ ~ |€€ ||‚ ‚
 

 *‚= *| | ~ =|} |} ("778 
 
 

'9;#+<#=;#+ <#>;##? #B8)

<>#?`?^{@?`\""G^<<?`< {@GQ@#\`GQ`
 

     
 
      
  
#



  



$ % & $ % &
    

…  
    
   
         >
…  
       
           
 
         
 
       ' 
  


  
      


    
…\ 
…
  
‡=
 
‡}  
      
    
     
     

            
      >  '

ƒZ*„ Z=„
Z}„'…† 
  
  
‡=    
‡
ˆ‰
    
       
 
 
   
!"#" # `   

      
   
 
` 



… 
     ‡

 
   
    
 
 
    
                
  
 
        
  
   
      
 

 ‡
     
 
 

 

‡

 

   
  '    
   
    

    
'
 

       

 <
}< 

 

598
 REFERENCES
[1] F. Raynal, Y. Berthier, P. Biondi, and D. Kaminsky, "Honeypot
Forensics, Part I: Analyzing the Network", IEEE Security &
Privacy, vol. 2, pp. 72-78, Jul-Aug 2004.
[2] F. R. Raynal, Y. Berthier, P. Biondi, and D. Kaminsky,
"Honeypot Forensics, Part II: Analyzing the Compromised
Host", Ieee Security & Privacy, vol. 2, pp. 77-80, Sep-Oct
2004.
[3] A. Chuvakin, "Honeynets: High Value Security Data", in
Network Security. vol. 2003, 2003, pp. 11-15.
[4] R. McGrew, "Experiences with Honeypot Systems:
Development, Deployment, and Analysis", in HICSS '06.
Proceedings of the 39th Annual Hawaii International
Conference on 2006, pp. 220a-220a.
[5] DFN-CERT, "European Network of Affined Honeypots -
Survey on the state-of-the-Art", Report Number: D0.1, 2005.
[6] R. Tber, "A Practical Comparison of Low and High
Interactivity Honeypots", in Information Security Institute. vol.
Master Australia Queensland University of Technology, 2005,
p. 51.
[7] H. Artaila, H. Safab, M. Sraja, I. Kuwatlya, and Z. Al-Masria,
"A Hybrid Honeypot Framework for Improving Intrusion
Detection Systems in Protecting Organizational Networks",
Comuters & Security, vol. 25, pp. 274-288, 2006.
[8] N. Krawetz, "Anti-honeypot Technology", in IEEE Security &
Privacy. vol. 2, 2004, pp. 76-79.
[9] S. Mukkamala, K. Yendrapalli, R. Basnet, M. K. Shankarapani,
and A. H. Sung, "Detection of Virtual Environments and Low
Interaction Honeypots", 2007, pp. 92-98.
599
[10] P. Defibaugh-Chavez, R. Veeraghattam, M. Kannappa, S.
Mukkamala, and A. H. Sung, "Network Based Detection of
Virtual Environments and Low Interaction Honeypots", in
Proceedings of the 2006 IEEE SMC, Workshop on Information
Assurance, 2006, pp. 283-289.
[11] F. Xinwen, Y. Wei, D. Cheng, T. Xuejun, K. Streff, and S.
Graham, "On Recognizing Virtual Honeypots and
Countermeasures", 2006, pp. 211-218.
[12] T. Holz and F. Raynal, "Detecting Honeypots and Other
Suspicious Environments", 2005, pp. 29-36.
[13] N. C. Rowe, "Measuring the Effectiveness of Honeypot
Counter-Counterdeception", in HICSS '06. Proceedings of the
39th Annual Hawaii International Conference on 2006, pp.
129c-129c.
[14] M. A. Davis, "Sebek", 3.0.4 ed New York, USA: The Honeynet
project, 2003.
[15] M. Dornseif, T. Holz, and C. N. Klein, "NoSEBrEaK -
Attacking Honeynets", 2004, pp. 123-129.
[16] L. Carter, "Setting Up a Honeypot Using a Bait and Switch
Router": SANS' Information Security Reading Room, 2004.
[17] Y. Geng, R. Chun-ming, and P. Lei, "A Novel Approach for
Redirecting Module in Honeypot Systems", The Journal of
China Universities of Posts and Telecommunications, vol. 12,
2005.
[18] P. Russell, "iptables", netfilter, http://www.netfilter.org/, 2007.
[19] M. Roesch, "Snort", Snort Sourcefire, 2007.
[20] R. Chandran and S. Pakala, "Simulating Networks with
Honeyd", 2003.
[21] Honeytrap: http://honeytrap.mwcollect.org/, 2007.