Stop CTRL+C Exiting Local Script Which is Running tcpdump in Remote Machine

Question

I have setup a simple script like the below:

sshpass -p $password ssh -T $username@$ip_address -p 30007 <<- EOF > $save_file.pcap
    sh
    tcpdump -i eth5.1 -s 0 -n -v -U -w -
EOF

sed -i '1d' $save_file.pcap

The purpose of this script is so that I can run a tcpdump on a remote device, yet save the output into a file on my local machine (the remote device has very limited storage capacity, so this would allow me to obtain much large captures, as well as, of course, allowing me to setup captures on demand much more quickly).

The purpose of the sh and the heredoc is because by default, I am not dropped into the appropriate shell of this remote device. Issuing sh in the remote device gets me to the proper shell to be able to run my tcpdump, and this heredoc is the only method I've found to accomplish this task and still port the information back into my local file.

The issue that I'm running into is that once the script gets to the tcpdump section of this script, my terminal is given output like the below, and like I would expect to see when running a tcpdump into a file:

drew@drew-Ubuntu-18:~/Desktop$ ./Script.sh 
tcpdump: listening on eth5.1, link-type EN10MB (Ethernet), capture size 65535 bytes
Got 665

And of course that "Got" counter increases as more packets are captured and piped into my local file. Unfortunately, the only method I have found thus far to stop this and return my terminal is to initiate a CTRL+C.

The issue here is that this doesn't only stop the tcpdump on the remote machine, but it ends the script that is running on my local machine.

This of course means that nothing further in my script is run, and there are many tasks that I need to perform with this data past just the sed that I included here.

I've tried to instead set things up like follows instead:

tcpdump -i eth5.1 -s 0 -n -v -U -w - &
read -n 1 -s; kill $!

The thought process here is that my raw tcpdump information would still be posting to stdout, and therefor still be populating in my local capture file. However, it seems like when I tried to run a capture in this manner, with the &, it didn't actually let me post anything else into the terminal (not sure if just too much junk flying at all times or what). I even tried this locally and it seems like trying to run a raw tcpdump posting to stdout doesn't let anything else happen.

Based on this information, the only thing I can think of at this point is if there is some manner in which I can use the CTRL+C in order to close out of the tcpdump on the remote machine, but keep my script still running. Any suggestions I can try? Or other methods of going about this that would be far more logical?

Answer 1

I suggest some improvements for your remote capturing traffic script:

1. preventing CTRC+C from killing your script:

   This can be done using a trap to capture SIGINT. You usually place it at the beginning of your script. See this example:

   trap "pkill ssh" INT
   

   Obviously, the filter to get the only the ssh you want can be improved.

2. Filtering out the communication with the remote machine from that tcpdump

   You telling us your system is not reacting well to the capture, might be a recursive data capture overloading the system. Depending on the interface you are listening to, you might be creating a recursive situation where in each connection you have with the remote machine, the controlling connection data will be added to the capture, which in turn will generate more packets to feed tcpdump.

   So your tcpdump might needs to filter out the communication between the local and remote machine. Use something similar to:

   /usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not port 22"
   

   or:

   /usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not my_local_host"
   

   This might alleviate the slowness and instability, so the script will behave better. See also later on, the point about using nc.

3. Limiting the number of packets in tcpdump to avoid having to use CTRC+C all the time.

   If you only want to capture a small set of traffic, you should limit the number of tcpdump packets captured by tcpdump.

   For instance for capturing 100 packets and returning:

   tcpdump -c 100 -w -
   

4. Limiting tcpdump in time to avoid using CTRC+C all the time.

   If you want to capture 5 minutes (300 seconds) of traffic, use the timeout command on the remote side. As in:

   ssh "timeout 300 tcpdump -w -"
   

5. Dropping that shell

   You are using the shell because you need $PATH to invoke tcpdump. Invoke the full tcpdump path instead.

   As in:

   sshpass -p $password ssh -T $username@$ip_address -p 30007 "/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w -"
   

6. unbuffering tcpdump

   tcpdump output to tcpdump to stdout is buffered. To unbuffer it to get data faster from the remote host, and lose less data when interrupting it, use -l:

   /usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -l -w -
   

   This might or might not be useful on your case, make some tests. It will sure left you more data on your side when you interrupt it with CTRL-C.

7. not using SSH for getting the traffic dumps. Use netcat instead.

   If you do not have so strict security requirements e.g. a capture inside your own network, and not have firewall(s) blocking ports in the way between the two hosts, drop that SSH for getting tcpdump output back. It is a computationally heavy protocol, and will get in the way if you need to capture more volume of remote traffic. Use nc instead to get the tcpdump data.

   As in local machine:

   nc -l -p 20000 > capture.dump &
   

   Remote machine:

   ssh remote "/usr/bin/tcpdump -w - | nc IP_local_machine 20000" > /dev/null
   

8. Dropping that sshpass

   Use ssh keys to authenticate instead of a password.

9. Lastly, if doing it more professionally, considering the possibility of using an agent + a professional service.

   You can do it using cshark.

   Capture traffic and upload it directly to CloudShark for analysis. Use the CloudShark service at https://www.cloudshark.org or your own CloudShark appliance.