Re: Introducing the Tactical Honeynet Deployment Project

[Chris Brenton <cbrenton () chrisbrenton org>]

Tom Britten wrote:
>     I agree with all of that, my concern and comment about building your own
> system from the ground up was not solely based upon the idea that you needed
> it look real after they have already broken in.  It was also from a concern
> of control standpoint (sorry i don't think i made it entirely clear the
> first).  An improperly configured honeypot/honeynet is a risk if not
> controlled,

LOL! I was just bitching to Lance about this in a private thread. ;-)

I *totally* agree. One of the things that really burns me is to report 
to a remote Admin that one of their IPs are attacking systems on my 
network, and to get back "Its OK, its just my honeypot". You are 
absolutely right, one of the big things here is maintaining control of 
the system. If you can't do that, you should not be deploying a 
honeypot. I teach SANS T2 a lot and this is something I beat into my 
students with a really big stick.

A couple of possible ideas:
1) Outbound filtering
One of the things Lance did early in the Honeynet (maybe even before 
there was a Honeynet? Lance, correct me here if I'm wrong.) was outbound 
filtering. Purps can get in, root the box, do what ever they want _to_ 
the box, but if they try to bounce out and attack other systems they get 
denied access. Use your imagination here. Something like iptables which 
can spoof back type 3's can make it look like they are having legit 
communication problems.

2) Virtual systems
I'm really big on setting up Honeypots as virtual systems. VMWare is OK, 
but User Mode Linux (UML) totally rocks. Jeff Dike has gone to great 
lengths to make a UML system look like a legit Linux box so its hard for 
the purp to figure out they've been sandboxed. One of the things I love 
about this solution is that you control the host system, not the purp, 
so you end up having the upper hand in the whole thing. This makes it 
much easier for someone who is not a guru to setup a honeypot and keep 
control over someone that may know more than they do.

> more so with news laws and the concept of legal liability coming
> into play.

And if for no other reason; "just so you don't make yourself to be part 
of the problem". ;-)

>     So I guess my original comment about building from the ground up was to
> address a plethora of problems that are encountered in deploying.
> controlling and monitoring honeypots/honeynets.  Hope that makes more sense

Totally. I think you have to look "outside the box" (pun intended :p) 
for this level of control as anything you do on the box itself can be 
detected/defeated by the purp. Again, this is one of the things I love 
about virtual systems. I've simulated a whole "classic 3 legged firewall 
config" using nothing but UML images on a single box and it works pretty 
cool.

HTH,
C