Reasons to redirect traffic to honeypots. Was: Re: URGENT regarding some doubts...

["Jack Whitsitt \(Jofny\)" <xaphan () violating us>]

Hello Tanmay, All:

> Hi...
> Our group is working on a project on honeypots...
> I had some doubts regarding your concept of redirection...
> I have a system which can be described as follows..
> 1> Gateway.....with Snort as IDS.
> 2> Honeypot
> 3> Real Computer
> 4> Log Server.
> Now when Snort detects an attack I would redirect the connection to
> Honeypot..   Now the problems are

> 1> If SNORT is detecting the attack then SNORT itself could block the
> ip instead of redirecting....This might lead to DOS attacks but we
> could block ips for only some specific period of time..How would
> redirecting help....??

Snort has been able to block connections for some time. There are problems
with this:
1: If you mistakenly drop your client's connection because of a false
positive then they see nothing. If you redirect them to a honeypot, they
may not notice that they've been redirected, so you may not upset your
client.
2: If you drop a connection from an attacker, you dont learn anything else
about them. Perhaps it was a mistake? Perhaps theyre going to try some
other way to get in now that they've been blocked? You don't know. By
redirecting to a honeypot, you know who your attacker is, what he's trying
to accomplish, can see if it's really hostile, and gather forensic
evidence for  possible legal prosecution. Plus, if he's busy attacking
(unknowingly) the honeypot then that's time that he's NOT spending
attacking your real machine.
As a side not: the Bait and Switch Honeypot System does account for a few
ways that the system can be DoS'd and attempts to deal with them. One of
these ways is limiting how long a source ip can be redirected. This is
user-configurable..
> 2> If the redirected computer is a Research
> Honeypot then it could be said that we want to learn new type of
> attacks...but then only those attacks that are detected by SNORT are
> redirected...these are the attacks you know abt from the start...so
> whats the adv.

There are 2 ways to do it that Im considering:

1: Most people (in my experience) hack into a machine through known holes.
However, what they do once theyre in is interesting...so your honeypot can
track what they do. Besides, most work is done encrypted after the initial
break-in, so snort wont be able to see what they do new - only the
honeypot.
2: Insert known bad data into your production machine. When you see this
data fly over your network you don't have to know the exploit - it will be
redirected on anyway.  You alert on bad data, keep track of the
surrounding traffic, and redirect the IP to the honeypot for to safely
gather additional information. This type of redirection is extremely
usefull since you can *know* that the redirection is not a false positive,
and because you dont have to have a rule for the bad traffic.
  3> Redirection can be used to save my Real computer
> from getting damaged and if something gets damaged let it be our
> honeypot.. Again the same point attacks not detected by SNORT would not
> be redirected so the real computer will be on threat..

Having your IDS miss traffic is why you a) have a firewall b) secure
hosts/servers c) run other audit trails. No solution is perfect or
provides complete coverage. In terms of redirecting traffic - if you tie
in snort, a HIDS system, and known-bad-data (honeytokens), you really have
a versatile solution.
4> Is it that my
> project will provide the same thing which would be provided by SNORT
> alone.. Please do reply...I am really in need for the answers to the
> above questions as I am stuck in my project badly... Waiting for ur
> reply..
> Regards,
> Tanmay

I'm not entirely sure what your project entails. Give me additional
specifics and I'd be happy to comment on them.
-Jack Whitsitt (jofny)
Violating Networks
http://www.violating.us/projects/baitnswitch/
http://baitnswitch.sourceforge.net