OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
IDS Archives: Re: IDS: RE: Honey pots / decoy servers

Re: IDS: RE: Honey pots / decoy servers

Martin Roesch (roeschclark.net)
Wed, 25 Aug 1999 16:39:27 -0400

FAQ: See http://www.ticm.com/kb/faq/idsfaq.html
IDS: See http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owneruow.edu.au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
USUBSCRIBE: email "unsubscribe ids" to majordomouow.edu.au
--------------------------------------------------------------------------- 

---
On Wed, 25 Aug 1999, Wagner Brett wrote:
> All,
> 
> I am not a "Honey Pot" expert however, I worked for Internetworking and
> their product GTE Sentinel was able to do this per the developers.  I
> know a little about this particular product and it seemed like a good
> choice.  I do not work there any longer so I do not think I am biased. 
> On another note can security professionals accomplish the same thing
> with deception tool kit and some other free tools?

Well, since someone else brought it up...

I'm the guy who actually wrote "Sentinel" when I was at GTE-I. (it wasn't called
that when I developed it...)  Sentinel is something like CyberCop Sting in that
it mimics a network of computers, but it can simulate an entire hetergenous
class C network, not just five computers, and it has many more fake services
(what I called "facade services"), including RPC and other fun stuff like that.

As far as the "Zen of Honeypots" is concerned, here's the my view on them.

Honeypots are a great way to improve your network IDS capabilities by providing
a "flytrap" to catch suspicious traffic that happens to be passing by. 
Generally speaking, "hackers" probe networks before attacking them (via
portscans, rpcinfo, CGI scanners, etc) looking for available services for which
they have some sort of exploit.  They then proceed to launch their exploit at
computers which they believe are vulnerable to attack.  This pattern can vary,
of course.  For example, and insider already knows where your high value
servers (targets) are and may attack them directly, skipping the initial
probing phase altogether.  Anyway,  a well configured honeypot can sit there
and look vulnerable *enough* to attract the interest of a hacker who is
performing the probe->exploit "classic" style of hacking/cracking.

I should note at this point that honeypots are something of a psychological
trap as well as a technical trap.  IOW, in order to set them up to best effect
you have to know how notional "hackers" think, and what services are attractive
to them.  You also need to be able to make a network look vulnerable enough,
but not too vulnerable, to avoid tipping off that there's something rotten in
Denmark. (not to offend our Danish readers...)  This is something of a
balancing act, but attention should be given to how the rest of your network
appears from the public internet.  If the whole network is locked down like
Fort Knox except for these five machines over here on this private little
subnet, attackers may think something is up.  Then again, they may not,
depending on their level of paranoia, etc.  As I said, honeypots are a game of
mind against mind as much as one of technology.

Rule Zero: If you don't know how attackers work, you can't set up a (good)
honeypot.

To continue, the primary thing that honeypots can do for your network
is "backstop" your network IDS.  This means that things which may get past your
NIDS often times will end up hitting your honeypot.  For instance, "slow
rolled" port scans (scanning a few ports a minute/hour/day) will be completely
missed by pretty much every NIDS out there (well, statistical and neural-network
systems may pick them up).  However, when that slow roll scan hits your
honeypot, it's going to record every packet that shows up at its doorstep and
let you analyze what's happening.  This is great for detecting: slow rolled
scans, new attacks (for the facade sevices your honeypot offers), attempted
backdoor access, and a plethora of other stuff that your NIDS doesn't look for.

Rule Number One: Everything that goes to your honeypot is
automatically suspicious!

This brings me to another idea, and something that annoys me about DTK.  One
thing you need to do at all costs is *not let people discover the fact that
you're running a honeypot*!  Discovery of your honeypot does two things for the
attacker.  First, it lets them know what to look for and what to avoid on their
target network (and every network that uses that system if it's commercial). 
Secondly, it reveals *far* too much about the defensive posture of your network.
 Optimally, you don't want the attacker to know that there are any defenses in
place on your network until the FBI is kicking in their front door.  If anyone
has read Greg Bear's "Anvil of Stars" novel, it's pretty much the same concept
as alien civilizations "armoring" themselves by trying to remain inconspicuous
until they can respond with overwhelming force.

This is precisely the reason that DTK annoys me.  It gives you the "DTK
service" which runs on a port (I forget which one) and announces to anyone
portscanning at least one method you're using to defend your network.  If there
are any exploitable weaknesses in DTK, you network can be attacked via this
method, plus the attacker can take advantage of your honeypot and mask their
real attacks by distracting you with bogus traffic.

Rule Number Two: Never let them know you're running an honeypot.

Now, there's some question as to whether or not attackers should be allowed into
"fishbowls" (what I call sandboxes) ala Cliff Stoll.  My personal feeling is
no.  Allowing a hostile party on to any node of your network for any reason is
bad news IMHO.  Psychologically speaking, the attacker is probably going to
notice that he is unable to do anything and that things don't seem right pretty
early in the game.  This may make him suspicious that he is actually in a
honeypot fishbowl, at which point he may decide to:

a) go away
b) take note of what he's found and spread the info amongst his peers
c) DoS your network/exploit known holes in your fishbowl
d) all of the above

There are also some technical reasons for wanting to avoid fishbowling.  The
primary (technical) reason I wanted to avoid it when building Sentinel was
because I didn't want to have to validate the incoming attacks.  For example,
if an attack comes in, a good honeypot will validate the attack against a
library of known exploits.  There is one big reason for doing this.  If the
attacker is truely suspicious/paranoid, he may try a bogus attack to see if it
still lets him in.  If it does, obviously he's got a honeypot on hand at which
point a-d from the last paragraph become viable responses.  Obviously this is
an untenable implementational detail, because the white hats out there will
never know every IMAP buffer overflow the black hat community has available. 
DTK has fishbowl functionality, which is another reason I don't like it. :)

There are a bunch of other issues when deploying/using honeypots (packet
logging vs session logging, reconfigure-ability, etc), but in general they are
an excellent additional layer of network defense.

Any questions? ;)

     -Marty

--
Martin Roesch
roeschclark.net
http://www.clark.net/~roesch

















This archive was generated by hypermail 2.0b3 
on Thu Aug 26 1999 - 06:35:29 CDT