I would rather say it is a network activity monitoring enhancement
methodology, which I will later devellop an IDS from. But as far as the
original concept of a honeystick was, that is to have client software to
stick out on the net and see what honey it falls on, besides having
automated client tools, the other solution involves using a crop of
users. I merely made suggestions as to how such a setup could look like,
along with the input of other posters here. On a dedicated honey network,
you can sniff your brains out and you will be sure to get all the honey
there is to get. But a dedicated network, along with automated client
scripts or fake users, are biased, and since production networks already
have users, and they are already going on Internet doing all kind of
things, one could be tempted to use such a network for honeysticking
purpose. Since sniffing is usually out of the question on prod networks,
for both legal and practical reasons, some other kind of monitoring has to
take place. Taken from there, I'm simply trying to fill a gap.

Also, let's not forget that the purpose of honeypot/net/stick/* is to learn
from the blackhat community, eventually in order to protect better from
it. At one point, honey*, IDS and network security procedures have to meet
somewhere, or else it's all useless.

Floydman

At 03:00 AM 03/09/2002, n b wrote:

>Hi
>
>I think what you say is a intrusion detection system (IDS).
>
>Nargess
>
>
>
> Floydman wrote:
>>Hi everybody. I'm glad someone came up with the idea
>>of a honeypot client (in the terms of client software
>>being exploited instead of server software), because I
>>have been working on something like this for a while.
>>But like Bill mentionned, the hardest part of it is to
>>have a user (typical if possible) to interact with the
>>clients so they become active. Client software,
>>unlike server, doesn't normally listen on a port, and
>>is simply idle when not used.
>>
>>So, maybe this means we have to take honeypot
>>technologies on the user desktop, since this is where
>>the user resides. Now, I know that what I'm saying
>>here goes to the opposite of what a honeypot is, and
>>we can't turn production machines into honeypots. The
>>most important reason behind it is for sniffing
>>purposes. But that being said, is there a way to
>>implement honeypot-related technologies into a
>>production network to monitor for client-side
>>exploits, without turning this network into a typical
>>honeypot? I think so.
>>
>>During my research period, I found a document entitled
>>"Protecting against the unknown", by Mixter
>>(http://packetstorm.acm.miami.edu/papers/contest/Mixter.txt),
>>which is a theorical paper, with some examples
>>implemented in Unix, about what I was trying to do in
>>the Windows world. At the same time, honeypots became
>>very popular (relatively speaking, of course). Which
>>brings me back to my own work, "Securing the internal
>>Microsoft network", "ComLog, a Win32 command prompt
>>logger" and "LogAgent 2.1, log file recollection
>>tools" (all available at
>>www.geocities.com/floydian_99. ComLog and LogAgent
>>executables can be downloaded from
>>http://securit.iquebec.com).
>>
>>To resume all these papers, let's just say that the
>>idea is to put access-control and logging ability to
>>the most application possible on all network nodes and
>>to collect these logs centrally, in a secured machine.
>>On Unix, this is relatively easy to do since the OS
>>and application source code is often available via
>>Open Source, and when a toold doesn't exist, that
>>admin will often craft a tool to fit his needs (it
>>also happens in the Win32 world, but less frequently).
>>
>>Now, in many of real world's networks, it is frequent
>>to see workstations with little or no security in
>>place, sharing open and outdated antivirus software
>>that logs alerts only locally. In Windows, there is
>>very little log in itself, and what is existing is
>>often ignored on the user's PCs. The idea behind my
>>paper is to implement at least some of Mixter's
>>recommandations on the Windows platform. First, by
>>centralizing application log files (LogAgent).
>>Second, by putting personnal firewalls on each machine
>>(and collecting logs, of course). Lastly, by securing
>>and patching the OS and applications to remove known
>>vulnerabilities (Pedestal Software makes a tool to do
>>this<http://rd.yahoo.com/finance/mailsig/new/*http://finance.yahoo.com>Yahoo!
>>Finance - Get real-time stock quotes

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]