Guy Harris <notificati...@github.com> wrote:
> Note also that there will be a configure-script option to enable this,
with the
> default being "no". Enabling remote capture increases the attack surface
of an
> application using libpcap, as it would receive messages from a
> not-necessarily-trusted remote host; the code to parse them needs to be
very
> careful. The code should, ideally, run without elevated privileges when
it's
> trying to open a remote capture source, as that's not needed, and, if
you're
> going to have a bigger attack surface, you don't want to run with elevated
> privileges.
Potentially, running rpcap:// over localhost may be a way to reduce need for
elevated priviledges.
Do you expect "tcpdump" to be the program run at the remote end, or will it
be something else?
> The stuff I'm working on has a table of URL schemes and routines to handle
> them, so that it could be extended to handle protocols other than rpcap.
For
> example, there could be "tcpdump+ssh", i.e. "ssh over to the remote
machine and
> run tcpdump", and there's a protocol that Wireshark dissects, in which
some
> 802.11 APs (Cisco and somebody else) send out packets over UDP -
Wildpackets'
> OmniPeek handles it directly, and it'd be nice if tcpdump/*Shark/etc.
could do
> so as well.
Yes to "tcpdump+ssh" URL...
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
