11

I'd love if there was a single command line tool for packet sniffing a single command in Linux. something like sniff dumpfile command so that you could just run the command you want to packet sniff in the terminal and get a dump of the packets somewhere else.

I'd like to dump / save / see only the network traffic of the single command that I enter, not all the TCP traffic on my single network interface. So if I was logged into my computer and had IRC running in the background, and I did sniff somefile wget http://www.google.com, I'd want to see all the network traffic that the wget command did to download http://www.google.com. I don't want 'somefile' to have the IRC network traffic confusing things.

There are lots of linux/unix commands that accept a different command and do something different. From sudo (run as superuser), nice change nice level, trickle (limit the bandwidth of a command)

2
  • 1
    What is it, exactly, that you want to do? Do you want to check whether a certain command is run? Do you want to sniff network traffic? Because using the phrase 'packet sniffing a command' makes no sense to me at all...
    – wzzrd
    Jun 22, 2009 at 15:14
  • wzzrd, see expanded question Jun 22, 2009 at 15:18

11 Answers 11

10

There isn't any that I know of, but it theoretically shouldn't be hard to get something similar. Strace can be used to intercept networking syscalls.

# strace -f -e trace=network -s 10000 /usr/bin/command arguments

This will give you information about the data sent between the kernel and the process. The output of strace isn't exactly what you'd want. However, strace uses the ptrace syscall to intercept system calls. It might be possible to write a program to output the data a little more usefully.

Alternatively, you can also intercept the nice useful socket, bind and listen syscalls. It might be possible to write a small program that used ptrace on these calls and libpcap to dynamically change the capture filter every time a new socket is opened.

3
  • It would be great if it output something that Wireshark could read. Jun 22, 2009 at 18:10
  • Bear in mind that the strace described above is accurate for Solaris (and possibly other commercial Unices). On Linux, strace is a system call tracer, similar in operation and output to truss on Solaris or tusc on HP-UX.
    – James F
    Jun 22, 2009 at 18:20
  • 1
    I described strace on Linux. Jun 22, 2009 at 18:56
8

Tracedump

Tracedump is a single application IP packet sniffer, which captures all TCP and UDP packets of a single Linux process.

Download and description here: http://mutrics.iitis.pl/tracedump

1
  • 1
    This should be the correct answer now.
    – h0tw1r3
    Jan 11, 2013 at 16:01
4

Try Wireshark -- the command will be tshark

  • tshark allows you to select filters on the traffic captured from an interface
  • use other utilities like the debian lsof to identify the kind of communication done by your application of interest.

Or, Do you really just want LSOF?


I don't think there is a tool that will dynamically keep filtering for all communication associated to a process. However, you could try tracking the process communications with tools like lsof and once you have a good filter that can isolate communication of that process from all other traffic running on your system, you could get the correct capture.

For, example, with wget usually the destination IP address is distinct from other process related traffic. Even if you take something like skype the destination port range is usually fixed for an instance.


This is a bit like the uncertainty principle. You can usually know what is going through a set of communication paths (with a sniffer filtering on identified group of flows), or where different communication links are being made (with lsof).

I would really like to know if both can be done for an application. I think it should be feasible. But, have not seen any tool do that yet.

1
  • lsof is awesome, but I'd rather see what it is doing / sending / recieving. Jun 22, 2009 at 15:26
4

Learn to use filter expressions.

Whilst this won't do the fancy trace stuff that you are asking for.

It will allow you to remove nearly all of the "confusing stuff like IRC" from the capture.

Additionally it's very useful to know the filter syntax for quick reference in the future.

2

Specifically for a web browser / web page something like the Firebug plug-in for Firefox may give you some of the information you are looking for: http://getfirebug.com/net.html

For more general applications, you may need to use netstat to identify the port(s) used by the application and then Wireshark/tshark/dtrace with a filter to capture just that traffic. Not the one line answer you were looking for though...

1

One idea, try VMWare

-setup a vm
-configure that vm to use a particular interface
-sniff on that interface from the host (its like a man in the middle attack)

If you isolate what network applications are running on that vm you might have your answer

A more ideal solution, I suppose, is to do what VMWare does in terms of how it specifies how it chooses an interface to talk over. I think its magic comes from the kernel modules it uses, in this case, probably vmnet kernel module.

To my knowledge applications are not aware for what interface they talk over and I believe this is by design; they shouldn't have to worry about such things.

Furthermore,
Perhaps a program already exists, I don't know. But if one was written you could call it nettrace (for example) and Usage could be like

nettrace program interface

then sniff the interface it uses and add routes (maybe it does the automatically) to your real interface

2
  • yes that would be possible. However it'd be great if there was a simple and quick tool to do it,. Jun 22, 2009 at 16:07
  • Maybe it is time for this simple tool? I wonder if it would be that difficult, probably vmnet mod could be a good starting point (though I don't know if there would be licensing issues). Perhaps (a hack) just use vmnet mod. I know I am interested in questions like this often.
    – rev
    Jun 22, 2009 at 17:13
1

Assuming that you are the only person on the box attempting to connect to google at the time, I'd think something like this should do the trick:

tcpdump -w <outfile> -i <interface> tcp dst host www.google.com and dst port 80

If you are not the only connection attempting to connect to google on the box, then if you can identify the IP/port you are connecting from you can also specify the src port/src ip.

Identifying the src port may be a problem unless you can specify it on whatever client you use. I'm not sure if you can with wget.

I strongly suspect that you can specify both src and dst ports with netcat so if it was really google you were interested in, you could do your GET (manually) through netcat.

Of course the man page will give you specifics

1

The tcpdump man page and many web sites give in-depth examples of filters, and there are even a few online repositories of tcpdump filter expressions. It should be able to do almost anything you can dream of, assuming that you know something about the network traffic (source, destination, ports, protocols, etc.) beyond just what program is generating it.

If you're working on a server or headless box, you can always have tcpdump write a dump file and then open it in Wireshark on your workstation and get advanced filtering and a graphical interface.

1
  • Erm, which switch to tcpdump command would limit it to a single application that generates the traffic? Jun 22, 2009 at 17:36
1

Maybe this script will do what you want with appropriate modifications to the tshark command:

#!/bin/bash

# Start tshark in the background before we run the commsnd to be sniffed.
# Add more options to tshark, as appropriate to your command....
setsid tshark  -w dump -i eth0 tcp port 8080 >/dev/null 2>&1  &

sleep 2

wget www.google.com

# tshark keeps running if you don't kill it. 
# This kills all other tsharks that may be running.
pkill -9 tshark

Read the dump file later:

tshark -r dump
2
  • You're capturing port 8080 but generating traffic on port 80; this won't do quite what you're intending.
    – James F
    Jun 22, 2009 at 18:18
  • James: My proxy connects to 8080, thats how I ran the script. I should have changed it 80 for the purpose of this post.
    – Not Now
    Jun 22, 2009 at 18:30
0

Dtrace should allow this, although I don't know whether it's quite made it into Linux yet.

0

The ptrace method used by tracedump was my initial idea, but it has some drawbacks. If it does what you need, stick with it. If not, there’s another approach you can consider

The problem with using the ptrace approach is that it’s very invasive. Per the documentation of tracedump, some applications will crash under some circumstances. It’s very difficult to do this elegantly with ptrace without that risk

Another high-level approach would be to utilize network namespaces - essentially per-process containerized networking- with a virtual Ethernet device pair to route and mirror traffic

Using this approach, the traffic from your process will always route through a single point, separate from other processes, creating an opportunity to capture it

Roughly:

  1. Create a new network namespace
  2. Create and configure a virtual Ethernet device pair
  3. Set up forwarding from the namespace via the virtual Ethernet device pair, using iptables
  4. Set up tcpdump on one of the virtual Ethernet devices
  5. Finally, move the process of interest into the new network namespace

Optionally, you could also modify the traffic using this method. You would redirect the traffic to a userland forwarder outside of the namespace rather than routing it directly via iptables. That userland application would be responsible for sending the packets on to their final location

For more on this general idea, the best resources would probably be guides on “transpart proxying”, even though most of those use-cases involve (effectively) rewriting a packet so that it uses a socks or http proxy to reach its destination (something you won’t want, except for certain types of applications)

There are plenty of potential problems with this approach, depending on the details of what you need to do and how the process communicates and operates. For example, potential problems may be:

  1. Handling traffic that goes to loopback
  2. Handling the case where the process forks, and you don’t want to capture the traffic of the child
  3. … plenty of other exceptional cases

So YMMV

Here are a few posts/docs that may help to understand this if you’re not familiar with it:

... they don’t perfectly fit your use-case, but they’re very closely related and they demonstrate the commands required to do per-process network isolation

I’m curious if there are any projects out there that help to automate this in a user-friendly way. I’ll add a reference if I find one as I currently do this manually, case-by-case

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .