Stripping payload from a tcpdump?

Question

Is there an automated way (either in tcpdump or via a helper app Out There) to generate a pcap file that contains only Ethernet, IP and Layer 4 (TCP in my case) headers, so that there is no payload/application data in the resulting pcap? I've found that since header sizes often vary, it's impossible to pick a capture size that won't catch any payload data.

Solution 1

You can strip out the TCP payload very easily with Python's scapy module

BEFORE

[mpenning@hotcoffee tshark_wd]$ tcpdump -n -r sample.pcap 
reading from file sample.pcap, link-type EN10MB (Ethernet)
00:25:42.443559 IP 192.168.12.237.1052 > 192.168.12.236.22: Flags [P.], 
    seq 2445372969:2445373021, ack 1889447842, win 63432, length 52
00:25:42.443607 IP 192.168.12.236.22 > 192.168.12.237.1052: Flags [.], 
    ack 52, win 65535, length 0
00:25:42.443980 IP 192.168.12.236.22 > 192.168.12.237.1052: Flags [P.], 
    seq 1:389, ack 52, win 65535, length 388

PAYLOAD STRIPPING

Running this as root in linux...

#!/usr/bin/env python
from scapy.all import *
INFILE = 'sample.pcap'
OUTFILE = 'stripped.pcap'
paks = rdpcap(INFILE)
for pak in paks:
    pak[TCP].remove_payload()
wrpcap(OUTFILE, paks)

AFTER

[mpenning@hotcoffee tshark_wd]$ tcpdump -n -r stripped.pcap 
reading from file sample.pcap, link-type EN10MB (Ethernet)
00:25:42.443559 IP truncated-ip - 52 bytes missing! 192.168.12.237.1052 
    > 192.168.12.236.22: Flags [P.], seq 2445372969:2445373021, 
    ack 1889447842, win 63432, length 52
00:25:42.443607 IP 192.168.12.236.22 > 192.168.12.237.1052: Flags [.], 
    ack 52, win 65535, length 0
00:25:42.443980 IP truncated-ip - 388 bytes missing! 192.168.12.236.22 
    > 192.168.12.237.1052: Flags [P.], seq 1:389, 
    ack 52, win 65535, length 388

In the tcpdump above, notice the "XX bytes missing!" messages. That is because we have removed the TCP payload.

Solution 2

If simple truncate would work for you, you could use:

tcpdump -i eth0 -s 96 -w test1.pcap

Later on you can analyze it with wireshark.

Comments

[Mike Pennington]

Unfortunately the OP is correct, there is no way to reliably predict the length of the TCP headers, due to the TCP Options field. For the most part, that is the only part of the IP / TCP headers that has a significant chance of differing in length. A fixed snaplen value does not guarantee that you always truncate the TCP payload in the correct place.

[adamdunson]

This sounds more like another question than an answer. Perhaps consider asking another.