[tcpdump-workers] Packet sanitization and IP masking (PR #615)
denis at ovsienko.info
Tue Aug 21 06:52:39 EDT 2018
---- On Wed, 13 Dec 2017 15:48:32 +0000 alice-cyberreboot <alice at cyberreboot.org> wrote ----
> Hello again,
> Here's a new update/summary of my PR:
> - Removed short options in favor of long ones for three features - zeroing out TCP/UDP payload in IPv4 packets (--zero-tcpudp-payload), removing said payloads completely (--no-tcpudp-payload), and masking external IP addresses to a given substitute IP (--mask-external-address mask_ip);
> - manpage documentation has been updated;
> - commits related to this PR have been consolidated into one commit message;
> - at the moment, currently up to date with upstream/master, including modifications resulting from ether.h being unavailable.
> Hope that at this stage, the PR is now ready for proper review.
> And again, if I can assist with work on fixing CVE-related issues, please let me know.
I have been thinking about the proposed design (making masking happen at the capture time in the same binary), and there is a possible design issue that bothers me.
Consider an end user with a really high rate/bandwidth capture rig. Their first objective would be to copy the packets from the wire to the storage, as quickly as possible to minimize the drops caused by the rig performance. The first problem is, with the additional per-packet processing the performance will drop, is that going to be visible?
The second objective would be to hand the capture over with masked endpoints, but what if they have more than one receiver with different mask length, or the mask length is later found to discard too many meaningful bits? It likely does not mean they have to make a new capture each time they need a different mask length.
I agree in some cases it is best to mask the endpoints right at the capture time, but do you see the use case for offline masking (as in "tcpdump -r infile.pcap -w outfile.pcap <masking parameters>")?
More information about the tcpdump-workers