Changes between Version 1 and Version 2 of AboutHoneyC

01/19/08 23:49:33 (11 years ago)



  • AboutHoneyC

    v1 v2  
    77The idea of client honeypots was first articulated by Lance Spitzner in June 2004. A few client honeypots have been created since then, namely Honeymonkey (Microsoft), !HoneyClient (available at, and of course Capture. These implementations crawl the web with a real browser (Internet Explorer) and perform analysis for exploit based on the state of the OS (such as monitoring changes to the file system, configuration, and process list) Since these implementations make use of real systems, they are classified as high interaction client honeypots. With HoneyC, we provide an implementation of a low interaction client honeypot. Such an low interaction implementation makes use of emulated clients (e.g. wget to emulate Internet Explorer) and analysis engine that might make use of an algorithm other than OS state inspection (e.g. signature matching). 
    911Figure 1 - HoneyC Component Diagram 
    1113HoneyC consists of three components as shown in Figure 1: Visitor, Queuer, and Analysis Engine. The Visitor is the component responsible to interact with the server. The Visitor usually makes a request to the server, consumes and processes the response. The Queuer is the component responsible to create a queue of servers for the Visitor to interact with. The Queuer can employ several algorithms to create the queue of servers (for example crawling, search engine integration). The Analysis Engine is the component responsible to evaluate whether security policy have been violated after the Visitor interacted with the server. Each of these components allows using pluggable modules to suit specific needs. This is achieved by loosely coupling the components via command redirection operator (pipes) and passing a serialized representation of the request and response objects via those pipes. This makes components implementation independent and interchangeable. For example, one could create a Queuer component that generates request objects via integration with a particular search engine API written in Ruby or one could also implement a Queuer component that crawls a network in C. 
    1317Figure 2 - HoneyC System Use Cases 
    1620It has to fill a queue of servers for the visitor to interact with. 
    1721After the interaction has taken place, the analysis engine has to determine whether the visit solicited an exploit from the server. 
    1925Figure3 - End-User Use Cases