Ethereal-dev: RE: [Ethereal-dev] ERTSP: Ethereal's RemoTe Sniffing Protocol

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Fulvio Risso" <fulvio.risso@xxxxxxxxx>
Date: Wed, 16 Feb 2005 20:40:44 +0100

> -----Original Message-----
> From: ethereal-dev-bounces@xxxxxxxxxxxx
> [mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of ronnie sahlberg
> Sent: mercoledi 16 febbraio 2005 10.17
> To: LEGO; Ethereal development
> Subject: Re: [Ethereal-dev] ERTSP: Ethereal's RemoTe Sniffing Protocol
>
>
> i belive  rpcap takes a pcap style capture filter which it applies
> locally before transmitting all packets that passes across to the
> capture client.
>
> problem is that rpcap is totally insecure

I partially agree.
rpcap does not take security in its highest concern.
However, rpcap is not totally insecure:
- it has an IP-based control
- it has an username/password login (although the password is transmitted in
clear; however, many protocols have this "feature", e.g POP3)
- the daemon comes "disabled" and you have to enable it explicitly


> and can not be used in any
> production environments for that reason.

This is not true.
I know of *many* companies which use rpcapd, mainly in data centers. For
instance, this protocol is in use in the Cisco Catalyst MDS 9000 and you
cannot say that this box is sold for home users only.


> adding an authentication phase with some simple mechanism such as chap
> should not be too difficult.


Probably you're right.
Is there anyone who volunteers to help me in this stuff?

Cheers,

	fulvio

> On Mon, 14 Feb 2005 18:27:51 +0100, LEGO <luis.ontanon@xxxxxxxxx> wrote:
> > Again, my intention is not just to remotize the capture process, it is
> > to create intelligent probes.
> > Probes that might be able even to filter transactions (for
> example using MATE).
> >
> > I think in telephony (my field) where I could put few different probes
> > arround the network and  be able to trace a sigle call's signalling
> > without transporting more frames than necessary.
> >
> >
> > On Mon, 14 Feb 2005 17:46:16 +0100, Gianluca Varenni
> <varenni@xxxxxxxxx> wrote:
> > > Hi.
> > >
> > > What about the remote capture features of WinPcap? WinPcap is able to
> > > capture from remote machines, and the code for the remote
> capture runs on
> > > windows and Linux (I'm not sure about BSD).
> > >
> > > More details can be found here
> > >
> > > http://winpcap.polito.it/docs/man/html/group__remote__help.html
> > >
> > > Have a nice day
> > > GV
> > >
> > >
> > > ----- Original Message -----
> > > From: "John McDermott" <jjm@xxxxxxxxxx>
> > > To: "LEGO" <luis.ontanon@xxxxxxxxx>
> > > Cc: <jjm@xxxxxxxxxx>; "Ethereal development"
> <ethereal-dev@xxxxxxxxxxxx>
> > > Sent: Monday, February 14, 2005 5:25 PM
> > > Subject: Re: [Ethereal-dev] ERTSP: Ethereal's RemoTe Sniffing Protocol
> > >
> > > >
> > > >>> > The Idea is a protocol to have sniffing clients and a
> sniffing servers
> > > >>> > communicate. Part like RTSP, and part like RTP+RTCP with
> > > >>> > retransmissions.
> > > >>> This sounds really cool and well thought out.  Maybe I'm missing
> > > >>> something, though.  What about RMON? Yes, it has another filtering
> > > >>> language and yes, it is not "real time" in the sense that
> Ethereal is,
> > > >>> but
> > > >>> mightn't it be an appropriate solution?  Then, Ethereal could
> > > >>> inter-operate with existing probes and so forth.
> > > >>
> > > >> The point is to be able to use display filters on the remote probe
> > > >> before packets are transmitted.
> > > >
> > > > Well, RMON does that, but it uses its own filtering
> language, and if we
> > > > want true Ethereal display filters, then, of course RMON is
> out (unless we
> > > > were to create a private filter MIB, I suppose...).  I just thought
> > > > interoperability might be useful.  I'm not convinced RMON
> is better than
> > > > your proposal, BTW, I just wanted to offer the thought.
> > > >
> > > > We discussed this in 1999/2000 so you might want to check
> the archives for
> > > > that discussion, too.
> > > >
> > > > --john
> > > >
> > > > _______________________________________________
> > > > Ethereal-dev mailing list
> > > > Ethereal-dev@xxxxxxxxxxxx
> > > > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> > > >
> > >
> > > _______________________________________________
> > > Ethereal-dev mailing list
> > > Ethereal-dev@xxxxxxxxxxxx
> > > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> > >
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev