Honeypots mailing list archives

RE: [inbox] Attack/Benign Packet Determination


From: "Roger A. Grimes" <rogerg () cox net>
Date: Fri, 29 Aug 2003 17:09:19 -0400

Where you place your honeypot will depend on your objectives.  You can place
it on its own subnet or in a production network (although there can be
strong data control issues to consider).

Any traffic to a honeypot, since it isn't a legitimate asset, is suspicious.
How do you determine the traffic is dangerous?  Merely because it seeks out
the honeypot.  Since it isn't  a production asset, nothing should be seeking
it by IP addresss, machine name, domain name, or any of its services.  So if
something touches it (beyond production broadcasts if it is in a production
network) then the traffic is suspicious.

The next generation honeypots are placing honeypots on the same network as
the production assets, but using "honeywalls" to direct suspicious traffic
to the honeypot.  You could put something inline between the honeypot and
everything else to make sure the hackers don't attack your production
assets...of course, that's only a concern with a full interaction honeypot
anyway.   I like the idea that outgoing honeypot traffic is automatically
sent to another honeypot session so the hacker thinks they are attacking
more and more assets, but are really just wrapped up inside a virtual
honeynet. Very cool.

Any low or mid-interaction honeypots wouldn't let the hacker gain enough
access to be able to do anything malicious.

I put low and mid-interaction honeypots inside on the production network as
an early warning system.  Not only do I get the early warning, but I can get
data that I would not otherwise get from an IDS.  Th way most people use an
IDS, it would (most likely) only collect the malicious traffic, but a
honeypot is collecting all traffic to it (in most instances), so you can get
the hacker's attack start to finish.  Yes, an IDS can easily collect
everything by default to, but most people don't use them that way (too much
noise).

My one-half cent.

Roger


***************************************************************************
*Roger A. Grimes, Computer Security Consultant
*CPA, MCSE (NT/2000), CNE (3/4), A+
*email: rogerg () cox net
*cell: 757-615-3355
*Author of Malicious Mobile Code:  Virus Protection for Windows by O'Reilly
*http://www.oreilly.com/catalog/malmobcode/
*Author of Apress's upcoming Honeypots for Windows
***************************************************************************


-----Original Message-----
From: Curt Purdy [mailto:purdy () tecman com]
Sent: Monday, April 15, 2002 4:44 PM
To: 'Steven DeFord'; honeypots () securityfocus com
Subject: RE: [inbox] Attack/Benign Packet Determination


The concept of a honeynet is to set aside a segment of your network, whether
a class C or .248 subnet that is seperate and unto itself.  Therefore any
traffic originating or destined is an indication of compromise, attack, or
scan.

I like to think of them as the miner's canary.  An early warning system that
quickly sends out alarms that don't have to be analyzed whether the traffic
is good or bad.  We have set aside a .128 segment and when snort goes of
here, we immediately look hard at the traffic.  We can then quite often just
block the source while they are still nawing at our soft underbelly before
they have a chance to touch our hardened assets.

Curt Purdy CISSP, GSEC, MCSE+I, CNE, CCDA
Information Security Engineer
DP Solutions
cpurdy () dpsol com
936.637.7977 ext. 121

----------------------------------------

If you spend more on coffee than on IT security, you will be hacked.
What's more, you deserve to be hacked.
-- White House cybersecurity adviser Richard Clarke



-----Original Message-----
From: Steven DeFord [mailto:steve () redlance singingtree com]
Sent: Friday, August 29, 2003 3:20 PM
To: honeypots () securityfocus com
Subject: [inbox] Attack/Benign Packet Determination


I'm new at this, so you'll have to excuse me, but in the handful of white
papers I've read, and from reading traffic on this list, I've not seen any
clear way that honeypot routers determine what traffic is bad (destined
for the honeypot) and which isn't.  People on the list seem to assume that
"All traffic on the honeynet is inherently an attack," but how does one
know which traffic is bad and which isn't?  At least, how do you tell any
better than an IDS?  For example, in a recent post, someone mentioned the
fact that a blackhat who's compromised a honeynet host can't get any
production information out of sniffing the network, but what if some
user's authentication session were misdirected to the honeynet?  Then the
blackhat could (essentially) passwordsniff legitimate users' logon
information, and could then infect production machines more easily.  The
only benefit of a honeynet, it seems, is improved logging, not due to more
accurate packet detection, but simply more loggers.  Could not, in theory,
one set up a honeynet in the production environment?  (Other than the
previously-mentioned problem of privacy laws and the like.)


Steven DeFord
steve () singingtree com



Current thread: