RE: Honeyd 0.7a Linux Toolkit - beta1

Hello Manuel,

to answer your router question, i do now know the d-link routers very well,
but most broadband routers are simple. You should to able to assign what is
often called a 'dmz host' (although the correctness of the term is
questionable) to which all traffic will be forwarded that is not explicitly
forwarded (for example to the web or mail server) somewhere else. That may
be what you are looking for. Alternatively you can, as you mentioned,
forward each port seperately to a seperate IP address, and make honeyd
machines to listen to each one.

Because i am not really interested in windows rpc, i tend to filter those
ports out at the firewall with a DROP before they can get logged. That means
a dropchain then is (simplified, my real logging is more complex) "drop
${rpcports[x]}, log all, drop all." Unless you are emulating windows boxes,
you might want to consider the same. If it is unavoidable to listen to
windows garbage coming from the internet, i feel your log daemons' pain.

If i recall correctly, tarpits were well explained in a recent security
focus article - take a look what you find.

Hope this helped, i'm a bit tired, so i hope i the answers fit to your
questions.

Chris Meidinger

-----Original Message-----
From: Manuel Lanctot [mailto:pacu_at_sympatico.ca]
Sent: Wednesday, December 17, 2003 1:43 AM
To: honeypots_at_securityfocus.com
Subject: Re: Honeyd 0.7a Linux Toolkit - beta1

Hi,

I've been using honeyd 5.0 for a while and was quite happy. I upgraded
recently to 0.7a and I've noticed two "typos" in honeyd.conf.bloat:
Line 104 & 111: The "add relay tcp port 111" line seems to be repeated twice

in the middle of the suse80 setup.

Honeyd is great and I have a lot of fun playing with, trying different
configurations. I have a question though.
I am between a D-Link router, which assigns a 192.168.0.x address to my
three
boxes behind it; one of them is a dedicated honeypot. So let's say my router

is 192.168.0.1, my webserver is 192.168.0.2, my desktop 192.168.0.4 and my
honeypot 192.168.0.4. Arpd grabs everything from 192.168.0.5 to .255.
Correct
me if I'm wrong but it doesn't make a lot of sense since there addresses
aren't available from outside my network.
So if I emulate 3 different mail servers, let's say on .10, .11 and .12 - I
have to actually redirect traffic to port 25 in my router configuration to
one of them; I can't use them all. Scanning that network doesn't give much
because nmap says it's a subnet... That's why honeyd currently runs a
webserver on some address, an open proxy on another, LDAP on another, etc.
Am
I right?

Another thing. I'm currently routing the traffic at the router level (port
25
-> .10, port 3128 -> .11, etc.) and my honeyd box itself has any traffic
directed to it. Would it be better to redirect all the incoming traffic to
the honeyd box (192.168.0.4) and let arpd re-redirect it to the right
spoofed
local address?

Almost last thing, which is a suggestion for the dev team. I'd like to see a

way to log by host, or by port. Right now, my logs are mostly filled with
port 135 connections and everything else is in the same file. I'd like to
have a way to say something like
log winbox 192.168.0.100 /var/log/0.100.log
in the honeyd .conf - or even something like:
add box tcp port 110 "/bin/sh scripts/pop3.sh" log "/var/log/port110.log"

Last thing, finally. I'm curious as to how exactly the "tarpit" function
works. I guess it's by setting the window to 0. If it's the case, I prefer
tarpitting to the iptables level. :) (though it's quite interesting when
used
with "dynamic" ).

Enough for now, keep up the good work Lance et al.

--
Manuel Lanctot
On December 15, 2003 10:55 pm, Lance Spitzner wrote:
> One my personal goals is to make it easier to use the
> advanced capabilities of Honeyd.  The new 0.7a Honeyd
> Toolkit is an attempt to do just that.  The Toolkit
> contains the following:
>
>  - Statically compiled Honeyd and Arpd binaries
>   (X86 Linux) and start-up scripts for easier
>    deployment.
>
>  - Collection of as many emulated services and scripts
>    I could find.  These scripts are organized based on
>    the OS they emulate, to make it easier to deploy
>    virtual honeypots.  If you know of any more, and would
>    like them added, please let me know.
>
>  - Honeyd.conf.bloat.  A configuration file that attempts
>    to create and demonstrate as many different templates
>    as possible.
>
> The Toolkit can definitely use some help, including new
> templates, added scripts, and any words of guidance or
> wisdom based on your experience.  You can give it a whirl
> at
>
>    http://www.tracking-hackers.com/solutions/honeyd/
>
> Any suggestions, contributions, or bugs greatly
> appreciated.
>
> Thanks!
>
> lance