Suggestion: Pcap-over-IP client support in tcpdump

[Erik Hjelmvik]

Hi all,

I've been using tcpdump and netcat to achieve what I call
"Pcap-over-IP", as described here:
http://www.netresec.com/?page=Blog&month=2011-09&post=Pcap-over-IP-in-NetworkMiner

This is a very simple solution that allows me to capture network
traffic from remote devices, such as firewalls etc.
However, it would be even better if tcpdump would have native support
for Pcap-over-IP so that I wouldn't have to use netcat.

What do you guys think? Would it be relevant to implement a
Pcap-over-IP client in tcpdump?

/erik

[Guy Harris]

Post by Erik Hjelmvik
What do you guys think? Would it be relevant to implement a
Pcap-over-IP client in tcpdump?

It sounds as if you mean "pcap-over-IP server" here, in that tcpdump would send network traffic over the wire to a client, such as {tcpdump, Wireshark, NetworkMiner, etc.}.

In that case, tcpdump might be overkill; you don't need tcpdump's dissection capabilities, for example.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

[Erik Hjelmvik]

Post by Guy Harris
It sounds as if you mean "pcap-over-IP server" here, in that tcpdump would send network traffic over the wire to a client, such as {tcpdump, Wireshark, NetworkMiner, etc.}.

Well, you are right in that my idea was for tcpdump to send libpcap
data over TCP to another machine. But I still consider tcpdump to be
the client here, since tcpdump would be the side that initiates the
TCP session.

Post by Guy Harris
In that case, tcpdump might be overkill; you don't need tcpdump's dissection capabilities, for example.

The reason for why it would be great to have in tcpdump is because
tcpdump is an ubiquitous tool that is available practically everywere.
Besides, there's nothing that would prevent tcpdump from being at the
receiving end of a "Pcap-over-IP" TCP socket.

However, I fully understand if you feel implementing a TCP listener or
TCP client in tcpdump would be a digression from the intended
functionality of tcpdump.

/erik

[Guy Harris]

Post by Erik Hjelmvik
The reason for why it would be great to have in tcpdump is because
tcpdump is an ubiquitous tool that is available practically everywere.

tcpdump-with-pcap-over-IP-support is a non-existent tool that is available nowhere. :-)

If the tcpdump distribution (or the libpcap distribution) were to ship with pcap_over_ip_d, it would probably become a tool that's exists on all platforms that would have had tcpdump-with-pcap-over-IP-support had such a program would have been shipped.

Post by Erik Hjelmvik
Besides, there's nothing that would prevent tcpdump from being at the
receiving end of a "Pcap-over-IP" TCP socket.

If by "receiving end" you mean that side that receives a stream of packets, no, nothing prevents that - and implementing the *sending* end in tcpdump would neither help nor hinder that; they're orthogonal. In any case, the receiving end arguably belongs in libpcap/WinPcap, so that other programs using libpcap could also be changed to support receiving pcap-over-IP streams.

Post by Erik Hjelmvik
However, I fully understand if you feel implementing a TCP listener or
TCP client in tcpdump would be a digression from the intended
functionality of tcpdump.

I think it a pcap-over-IP packet sender would be a useful tool to put into either the tcpdump or libpcap project, but I don't see any reason why it necessarily needs to be a part of the tcpdump program.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

[Michael Richardson]

Guy> If by "receiving end" you mean that side that receives a stream
Guy> of packets, no, nothing prevents that - and implementing the
Guy> *sending* end in tcpdump would neither help nor hinder that;
Guy> they're orthogonal. In any case, the receiving end arguably
Guy> belongs in libpcap/WinPcap, so that other programs using
Guy> libpcap could also be changed to support receiving pcap-over-IP
Guy> streams.

Yes, in libpcap.
But, do we need to do anything other than popen("netcat *someargs*")??

[Francois Goudal]

Post by Erik Hjelmvik
The reason for why it would be great to have in tcpdump is because
tcpdump is an ubiquitous tool that is available practically everywere.
Besides, there's nothing that would prevent tcpdump from being at the
receiving end of a "Pcap-over-IP" TCP socket.
However, I fully understand if you feel implementing a TCP listener or
TCP client in tcpdump would be a digression from the intended
functionality of tcpdump.

Hi,

I just wanted to say that I disagree with that fact. tcpdump is a tool
which is available practically everywhere, true. So is ssh, and ssh will
let you pipe a stream to a remote computer.
The usual philosophy in Unix is that a tool does one thing, and does it
well, and if you want to do fancy things, then you can combine several
tools.

Here is the perfect example of such a combination. You capture frames
with tcpdump, and you send them live with ssh. Tcpdump can output the
pcap stream on its standard output, and this has not been made for
humans, since a pcap binary stream is not something a human can read. So
if this feature is there, it must have an interest, like for example,
being able to pipe it to another tool, such as ssh.
So the remote feature you are seeking is actually already there, it's
just not 100% built-in, but tcpdump's goal is to capture frames, not to
send them over the network, while ssh purpose is to establish a secure
data stream over a network.

Netcat (nc) is not always installed on a computer, but it's very rare
ssh is not installed. It may be too much because it doesn't only streams
over tcp, but also ciphers, but it works well.

Implementing a TCP sender in tcpdump might look easy at a first glance,
but it's first of all reinventing the wheel since there are already ways
to get the same result, also it's more source code to maintain, and
which has nothing to do with the purpose of tcpdump which is capturing
frames to a pcap stream, and it may also be a source of bugs, crashes,
security issues, etc... and I think the tcpdump developers should focus
on what they are good at while some other devs can build powerful and
secure tools to stream over a network.

That's just my point of view, but I think that's how Unix tools have
been designed so far, and I think it's great, and I don't see any
advantage in getting away from that model, especially when computers
nowadays have no problems in running 2 processes to perform a task,
instead of doing it all in one. (and it may even be better to do it this
way since the industry has moved to multi-core architectures, so 2
processes would be more efficient than one single-threaded process).

You can take a look at this page, if you want to do what I described
(pipe tcpdump to ssh) :
http://www.looke.ch/wp/monitoring-a-remote-network-interface-with-tcpdump-and-wireshark

Best regards

[Rick Jones]

What are the issues/benefits/downfalls one way or t'other between the
two schemes - over ssh and a specific connection - when it comes to
making certain that this thing forwarding captured traffic isn't simply
chasing its own tail forwarding captures of its forwarding of captures
of its fowarding of captures...

rick jones

[Michael Richardson]

Rick> What are the issues/benefits/downfalls one way or t'other
Rick> between the two schemes - over ssh and a specific connection -
Rick> when it comes to making certain that this thing forwarding
Rick> captured traffic isn't simply chasing its own tail forwarding
Rick> captures of its forwarding of captures of its fowarding of
Rick> captures...

The issue is threefold:
1) libpcap, does not currently expose itself to the network in
through sockets. Any new code (particularly "server" code)
would increase risk.
(Yes, tcpdump has lots of vulnerabilities to buffer overflows,
but pcap doesn't really have the same issue, since it never
looks in the packets it captures)

2) anything we do which is "native", will be wrong for some use, and
any security we write will be wrong, and need to be extended, and
then will become complicated and brittle...

3) therefore, it's better to reuse the existing tools, which already
come in a variety of flavours (ssh, ssl, kerberos, passport,
https, oauth, socks, raw, rlogin, ...) rather than inventing
something new.

The push back is usually from the microsoft platform, designed only really to
load word, doesn't really provide any way to combine differing tools in new
ways. Ironically, windows has some of the best integrated security
authorization in the form of kerberos enabled AD, but doesn't provide a
simple equivalent to "ssh remotehost command" that uses AD.

[r***@happyleptic.org]

-[ Wed, Sep 14, 2011 at 09:56:59AM -0700, Rick Jones ]----

Post by Rick Jones
What are the issues/benefits/downfalls one way or t'other between the
two schemes - over ssh and a specific connection - when it comes to
making certain that this thing forwarding captured traffic isn't simply
chasing its own tail forwarding captures of its forwarding of captures
of its fowarding of captures...

Isn't it the same problem that any person running tcpdump through a ssh
connection already routinely handle ? Ie. displaying the packets of the
ssh connection that displays the packets... Which is easily solved by
filtering ssh out. Same can be done here by the OP.

[Michael Richardson]

Erik> I've been using tcpdump and netcat to achieve what I call
Erik> "Pcap-over-IP", as described here:
Erik> http://www.netresec.com/?page=Blog&month=2011-09&post=Pcap-over-IP-in-NetworkMiner

Erik> This is a very simple solution that allows me to capture
Erik> network traffic from remote devices, such as firewalls etc.
Erik> However, it would be even better if tcpdump would have native
Erik> support for Pcap-over-IP so that I wouldn't have to use
Erik> netcat.

Erik> What do you guys think? Would it be relevant to implement a
Erik> Pcap-over-IP client in tcpdump?

On your server side, you are, I think done.

What you want, on the client side, is the ability to open a socket.
Instead of doing that, we should permit -r to take something that it
feeds to popen().

Or, the other question is... why not use /dev/fd and some shell script?