About HoneyC
HoneyC is a low interaction client honeypot. Before we describe HoneyC in detail, let us provide some background information around honeypots and client honeypots.
Honeypots, in general, are dedicated devices whose value lies in being probed, attacked, and compromised. Traditionally honeypots are server components that passively wait to be attacked. These honeypots allow to capture active attacks, such as worms. Client honeypots turn around this situation. Instead of passively awaiting to be attacked, client honeypots actively crawl the web to search for servers that exploit the client as part of the server response.
The idea of client honeypots was first articulated by Lance Spitzer in June 2004. A few client honeypots have been created since then, namely Honeymonkey (Microsoft), HoneyClient (available at www.honeyclient.org ). 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).
Figure 1 – HoneyC Component Diagram
HoneyC 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.
Figure 2 – HoneyC System Use Cases
Figure 2 shows some of the system use cases that HoneyC fulfills.
It has to fill a queue of servers for the visitor to interact with.
After the interaction has taken place, the analysis engine has to determine whether the visit solicited an exploit from the server.
Figure3 – End-User Use Cases
Figure 3 shows how an end user interacts with HoneyC.
From the basic start and force stop function (HoneyC stops automatically after the queue can not be filled anymore), the user should be able to configure HoneyC in the matter described above.
The user should be able to change and adjust the Visitor, Queuer, and Analysis Engine to meet the specific needs of the crawl.
After a crawl has been completed, the user should be able to view a report that lists servers visited and which servers solicited a malicious response.
This work is licensed under a Creative Commons License