Re: [Hawkeye-devel] Multiple capture interfaces

[Rob J M. <rm...@xs...>]

On Sun, 9 Oct 2005, Sebastien Raveau wrote:

> On Sunday 09 October 2005 16:09, Rob J Meijer wrote:
> > I think that maybe if we could seperate this into a single capture data
> > dispatching process, and multiple capture processes, than this would allow
> > for a cleaner incorporation of user space bridge mode stuff.
>
> The idea of having several capture processes at a time has been raised many
> times, but I still can't decide wether to implement this possibility or not,
> as I am not comfortable with the extra load the genericity would generate...
> I'd rather wait for a really working hawKeye (which I hope we will achieve in
> a few weeks) and see how it behaves under the load generated by a typical
> LAN, to get a feel on how much more sophistication we can put into it.
>
> Could you please elaborate on the "user space bridge mode stuff"?
> I just re-read the docs you sent me, but I'm still not sure what it is for :)

The basic concept would be having your system running hawkeye run as a
physical man in the midle device. This would mean you will have two
ethernet devices, neither one configured as part of any network, and in
basic transparant mode, you would simply capture all data on one device
and (for the data you did not transmit yourself) retransmit that exact
same data on the other device. This would mean your system would in basic
operation run as a user space ethernet bridge.


> > I would be interested in building this capture data dispatcher, and moving
>
> Thanks for the interest ;)
>
> > the current hard coded syn/ack + dns dispatching to a configuration file.
>
> Why have a configuration file for that?
> Unless you have a better idea, DNS packets should always be forwarded to the
> DNS cache (hawkeye_dns) and the graphical user interface (hawkeye_gui) should
> always be notified of opening connections. I mean, in my opinion these are
> hawKeye internals that the user need not know about.

I would think if you build a generic capture data dispatcher, that
would next to the basic hawkeye operations be build to allow mitm
modules to be registered for data adhering to specified rules, than
any hard coded dispatching rules could be replaced by either a simple
config file based aproache, or a somewhat more advanced registration
patern where gui and dns cache would behave like mitm modules and register
itself as being interested in ....
The second aproach would be cleaner but a bit more work.

> > For the capture process this would mean that it would send all of its data
> > to the capture data dispatcher and prefix it with an interface id.
> > I would like to combine dispatching with persistent priority queueing
> > (libppq) as some real time data processing or GUI displaying may be time
> > consuming in such a way that hawkeye might not be able to keep up with
> > all the captured data.
>
> Yeah, performance is the #1 issue in hawKeye...
>
> > If the same config file could supply rules for
> > dispatching priorities, this might help to avoid problems in keeping up
> > capture speeds. But maybe I've missed something in the current design
> > taking care of this last issue, I might have as the whole design is not
> > yet 100% clear to me.
>
> Indeed, I think you and me should have a chat on IRC (whenever you can join)
> to make things clear :)

Ok, Ill try, what timewindow are you on IRC? and can I have the IRC server
name again?

> > If you guys think it usefull that I would be working on a seperate
> > dispatcher process, I would also like to try and update the
> > autoconf/automake stuff as to supply a disable option for the
> > GUI stuff that would not check for X headers, Qt library, kde
> > headers etc, and build anything but the GUI. I would like to use
> > the non gui core of HawKeye and add a basic MITM framework to it
> > that would be usefull for hawkeye as a GUI tool I believe,
> > but would also be able to run without a GUI on a simple appliance.
>
> I don't see what you could do with it, without a GUI at all...
> Wouldn't it be possible to just have a probe on the appliance, and use the
> remote capture feature in hawKeye?

My Lipax project aims to make a small debian based linux distribution for
geode based apliances with multiple network cards, that should  be used
in the context of the trusted workstation section of a security audit.
The basic idea is that inside a company you take a standard workstation,
plug the appliance between the workstation and the company its network,
use a non priviledged user account and perform a wide range of  standard
operations using the there installed software.
The device should than gather all relevant information, and when needed to
gather more information, could use MITM techniques, or could supply a
webinterface or in some cases a shell to the user of the workstation in
order to manualy run more tests.

Most of the work for this customized linux distribution would go into the
MITM stuff. My first interest for HawKeye would for that reason also be
in the possibility of embedding my MITM framework ideas into it in some
way usefull for HawkEye, but also a way that would allow it to run just
the MITM stuff without the HawkEye GUI. The GUI would be very usefull when
using a laptop for user space bridge stuff with possibly added MITM
modules, but the Lipax appliance wont have real time access to a network
with a GUI, but would need real-time access to the MITM modules.

Maybe I could now work on a short design for a generic capture data
dispatcher that can work with priorities (and persistent backlogs),
and with multiple capture processes. If I have that paper ready in two
or 4 weeks also, that may be a good time to see if you would want to use
such a design.