Re: Camouflaging Honeyd

[Xinwen Fu <xinwenfu () cs tamu edu>]

Hi,
> I'm just a bit confused on this partly because I understand honeypots
> but not in detail. I just want to verify that this patch increases the
> accuracy that a Honeyd has for simulating a link between two virtual
> hosts it's running and the world at large by changing the minimum
> value it can emulate. The problem being that currently the latency is
> not realistic and this will fix it. Is that correct?

        This patch is for people using honeyd to simulate
networks. For example, config.sample shipped with honeyd 1.0 is such a
case. There are routers/switches in the
network topology configuration (or hosts communicating with each other
in a virtual network. Can honeyd do that?).

        The original honeyd cannot support a realistic network setting
because of its 1ms link latency accuracy and OS timing limitation.
You have to patch your honeyd code and your OS based on our instructions.
Of course, there are other ways to do
this. I will provide a technical report soon for the related issue.

Best,

Xinwen

> On 7/25/05, Xinwen Fu <xinwenfu () cs tamu edu> wrote:
> > Hi, Guys,
> >
> >         A lengthy email is below. Thanks for reading and comments are
> > welcome :).
> >
> > Camouflaging Honeyd
> >
> > Code by Bryan Graham and Xinwen Fu
> >
> > You can find all the files related to the discussion here at
> > http://students.cs.tamu.edu/xinwenfu/honeyd_tamu/.
> >
> > Honeypots are decoys designed to attract attackers. We can deploy honeypots,
> > log the attacker's activities, analyze her behavior and design new
> > approaches to defend against her. A virtual honeypot can simulate/emulate multiple
> > honeypots on one physical machine and it has decent flexibility. We propose
> > camouflaging virtual honeypots. A virtual honeypot needs to hide itself and this is
> > analogous to the fact that an experienced sniper needs professional camouflage. We
> > find it difficult to design an appropriate "camouflage" for a virtual
> > honeypot. In particular, Honeyd is a virtual honeypot and can simulate any
> > dimension of network on one physical machine or multiple machines. We find
> > that an attacker may remotely fingerprint honeyd by measuring the link
> > latency of the network emulated by honeyd. We design a camouflaged honeyd by improving
> > the honeyd toolkits and patching the Operating System (OS).
> >
> > The major problem of the networks emulated by honeyd is that it relies on
> > the underlying operating system for emulation accuracy. Then, if it is
> > Linux 2.4 or lower, the timing accuracy is 10ms. This means the emulation
> > accuracy of the link latency is 10ms
> > under Linux 2.4 while 1ms under Linux 2.6. Such a big link latency is
> > awkward within a metropolitan network (MAN). The attacker can build
> > profiles of such a honeyd offline.
> > Thus, if an attacker can remotely measure the link latency and find that
> > the link latency matches the built fingerprinting profiles, the attacker
> > knows the corresponding link is emulated by honeyd. Then honeyd is
> > remotely detected.
> >
> > The basic idea of camouflaging honeyd is to make its behavior not protrude
> > in its surrounding networks. Thus, honeyd and the underlying OS have to
> > support link latency of 1us. This is the first step to camouflage honeyd.
> > We will provide a technical report on the whole camouflaging issue later.
> > Here are instructions to make the first step.
> >
> > 1. Make your libevent use "select" for the timing
> >
> >         Comment out the definitions of HAVE_EPOLL and HAVE_POLL in
> > config.h, and then remake your libevent library. Under some systems, maybe only one of
> > the two definitions appears. Refer to our config.h.
> >
> > ------------------------------------------------------------------------------------
> > /* Define if your system supports the epoll system calls */
> > //#define HAVE_EPOLL 1  comment out
> >
> > /* Define if you have the `poll' function. */
> > //#define HAVE_POLL 1
> > -------------------------------------------------------------------------------------
> >
> > 2. Make your honeyd (1.0) support 1us link latency
> >
> >         Copy our honeyd.c and lex.l to your honeyd source code directory,
> > and rebuild your honeyd.
> >
> > 3. Patch your kernel (2.6.10) to support high resolution timing
> >
> >         Apply TAMU-2.6.10-hz.patch here to Linux 2.6.10 kernel. By changing
> > the parameters of "HZ" and "USER_HZ" in the file
> > /usr/src/linux2.6.10/include/asm/param.h, you can alter
> > OS's timing resolution. We recommend a timing resolution of 50us. Refer to
> > our param.h.
> >
> > -------------------------------------------------------------------------------------
> > # define HZ             20000           /* Internal kernel timer frequency
> > */
> > # define USER_HZ        2000            /* .. some user interfaces are in
> > "ticks" */
> > -------------------------------------------------------------------------------------
> >
> >
> >
> > Xinwen Fu
> >
> > -----------------------------------------------------------------------
> > "I must cool myself and think; for it is easier to shout 'stop!' than to
> > do it." --- Treebeard
>
>
> --
> ChayoteMu
>
> "To catch a thief, think like a thief. To catch a master thief, be a
> master thief."