Remote Packet Capture

Capturing packets is mostly a local task; we start up a packet capture tool that listens on a local network interface and either analyzes the packets or saves them to a local file. That raises a question: what if I want to do the capture on a remote computer and analyze them locally or save them to a drive somewhere else with more disk space? Alternatively, could I save them to my own laptop to avoid saving anything to disk on a system that needs to go through forensic analysis?

We can handle either scenario with the same technique; we’ll run the packet capture remotely but bring the packets back to our local system for either analysis or storage. This is especially handy if the remote system simply cannot run the tool we want to run.

 

Remote Capture With Saving to a Local File

Let’s start off with an example where my laptop has IP address 192.168.0.11 and the machine on which I want to capture packets (“carla”) has IP address 192.168.0.238. You’ll need to adjust this hostname and the IP addresses for the systems you’re using, as well as the interface name:

ssh root@carla tcpdump -i eth0 -qn -U -w - 'not \(tcp port 22 and host 192.168.0.11 and host 192.168.0.238\)' >/tmp/remote.pcap

Bear with me. 🙂

Overview: We’re running tcpdump on the remote system inside an ssh connection, telling it to push the packets back over the ssh connection and save them locally to disk.

Here are the details: We’re ssh’ing to host carla and logging in directly as root. Note that we’ll need to have keys set up to allow logging in as the root user, as it’s not practical to enter a password either for login or for sudo because we can’t see the password prompt. As part of this ssh command, we’re specifying that we want to run a single command:

tcpdump -i eth0 -qn -U -w - 'not \(tcp port 22 and host 192.168.0.11 and host 192.168.0.238\)'

Let’s take a look at the components.

“tcpdump -i eth0 -qn” says to capture packets off eth0, don’t say much, and don’t look up hostnames for the IP addresses. We’re using “-w – ” to tell tcpdump to write the packets to “-” (the minus sign) which writes them to standard output. ssh sees this output and brings it back to the laptop.

The “-U” tells tcpdump to write these immediately rather than waiting to fill stdout’s buffer and then write a bunch.

This last bit inside single quotes is important. Remember, we’re ssh’d from 192.168.0.11 to 192.168.0.238. Every time tcpdump hands us a packet, it generates another ssh packet to send us the first one! That packet needs to be reported on, so tcpdump needs to generate another one, and so on, and so on, and so on… To avoid this infinite loop, we tell tcpdump to report on everything except the ssh connection(s) between these two systems. That’s what the ‘not \(tcp port 22 and host 192.168.0.11 and host 192.168.0.238\)’ does.

Note that the remote part is everything between “ssh” and “\)'”. The “>/tmp/remote.pcap” is running on this laptop; it grabs everything coming back from the remote system (a stream of packets in pcap format) and saves them in the file /tmp/remote.pcap . This might seem odd at first — the output of anything happening over a ssh connection is usually printed to my local screen, but here I’m forcing it all to disk. It turns out this is totally reasonable; ssh is glad to pass back either console traffic or raw data (packets), and we’re using the latter to save the packets in pcap format.

As this runs, the packets will be saved to /tmp/remote.pcap . On Linux, MacOS, and the other Unixes, you can read packets out of that file while they’re still being added by the above command! Try opening a new command window on your laptop and run the following:

tcpdump -qtnp -r /tmp/remote.pcap

This will read all packets that have been sent so far and display a one-line summary of each. You can use any tool you’d like — it doesn’t have to be the same as the program doing the capture on the remote system. If you’d like to analyze this pcap file with pcap_stats (https://github.com/activecm/pcap-stats), for example, you could run:

pcap_stats.py -r /tmp/remote.pcap -c 10000 -m 1000

 

Remote Packet Capture; Local Analysis

You have the option of feeding packets directly into another analysis tool if you prefer:

ssh root@carla tcpdump -i eth0 -qn -U -w - 'not \(tcp port 22 and host 192.168.0.11 and host 192.168.0.238\)' | pcap_stats.py -r - -c 10000 -m 1000

Instead of sending packets to disk first and then coming back to analyze them later, we’re sending these packets directly into the analysis program. Note that pcap_stats.py is using “-r – ” to read its packets from stdin. You’ll need to check your analysis program’s man page to see what command line options tell it to read packets from stdin.

 

Notes

• You need to set up ssh keys to permit root login because any password requests (for initial login or sudo) will be redirected to your pcap file, corrupting the file.
• You have to put in the bpf filter mentioned above or else you’ll have an infinite loop that will quickly saturate your network cable and fill the disk.
• If you’re trying to avoid saving packets to the remote disk because you’re planning to do forensic analysis of it, be aware that the simple act of logging in will cause a small number of disk writes. These will still be many orders of magnitude fewer than the impact of saving the packets to disk and transferring them later.
• To set up ssh keys easily, try sshprep (https://github.com/william-stearns/sshprep). More details at https://www.activecountermeasures.com/our-top-ten-network-tools-and-techniques/ and https://www.youtube.com/watch?v=62hps0XZkN8 .
• Because there’s only a single ssh channel, you can’t use techniques like log file rotation with the remote tcpdump command. However, you can bring the packets back to your laptop and use tcpdump on your laptop to do the log rotation locally every 60 minutes:

ssh root@carla tcpdump -i eth0 -qn -U -w - 'not \(tcp port 22 and host 192.168.0.11 and host 192.168.0.238\)' | tcpdump -r - -G 3600 -w /tmp/remote.%Y%m%d%H%M%S.pcap -z bzip2

• If logging in as root is not possible or banned by policy, see https://www.activecountermeasures.com/permission-to-capture-packets/ for other ways to launch tcpdump that don’t require direct root login.