tcpdump/argus anonymizer

[Peter Van Epp]

> 
> Hey Peter,
> Looks like it fails on a partial fragment that contains only
> 1 packet.  Maybe that will be enough.
> 
> I did start on a tcpdump anonymizer and got pretty far along,
> at least I can read them, and write them back out
> with no problems, and I can change the times in all
> the packets.  This is going to be a major effort, but I
> think I'll have something early next week.

	If you ship me whats done now I expect I can arrange to replace the
data section with ' ' (for instance) and forward a copy of the failing trace.


> 
> So I'm going to give someone the opportunity to change all
> the MAC and IP addresses, change the times and zero out
> user data above the transport headers for the protocols
> that tcpdump supports.
> 
> So I'll read in every packet to get the MAC and IP address
> inventory, and then formulate a conversion table.  The
> conversion will try to preserve the address hierarchy, so
> relationships between hosts can be preserved.  So broadcast
> and multicast addresses will be preserved, but the actual
> addresses will be different.  For MAC addresses, I'll keep
> the vendor ID, and the multicast addresses intact.
> 

	Yep, I expect this is going to be the exciting part, because not only
do you want to change it but you want to remember the mapping and search for
it reasonably efficiently to replace it in subsequent packets. 

> Do we want to change ports?

	I don't think so, that shouldn't be sensitve and may be important 
to debugging (in non argus cases at least :-))

> 
> Rather than try to be cleaver modifying IP addresses in
> things like DNS requests and answers, I'll just limit the
> first pass to anonymize after the transport headers.
> 
> I'll recalculate cksums so that the new packets are all valid
> packets.  I'll write specified strings into user data areas.
> I'll try to truncate the packets, but if I can't I'll just
> write in a repeating string when I need to write over user
> data.

	Sounds like a reasonable idea and should cover all privacy concerns
I can think of. If the data is sensitive enough that things like port numbers
and packet frequency are an issue it is probably to sensitive to anonymize as
well. I'm really looking for something (at least in this instance) that replaces
the user data with something harmless so I don't need to worry about things
like passwords in the data. Even the MAC addresses in my particular case aren't
vital because I'm between two routers and their MAC addresses aren't 
particularly secret and don't compromise the id of the machines involved.

> 
> The same logic will apply to argus records, so this is not
> wasted time.
> 
> Can you think of anything else?
> 
> Carter
> 
	
	Lots of things (but not necessarily for argus entirely :-)). I was
looking at packetforge.net (home of libnet) last night to see if anyone had
already done editing tcpdump files (which they don't seem to have) and was
thinking that for tcpreplay a packet editor that emits tcpdump records would
be ideal. It would be nice (but a lot of work!) to be able to edit a tcpdump
file (and be able to create a crafted tcpdump file) for use by tcpreplay.
Basically be able to capture a live transaction either with tcpdump sniffing
the wire and idealize it (i.e remove any errors or retransmissions) edit the
data in any way you choose and then be able to play it back with the option
of inserting errors of various kinds in to the outgoing data stream for testing
purposes (with the advantage that it is repeatable). It would also be nice to 
be able to "create" a tcp or udp stream from the editor where the user feeds 
in the data that should go across the "link" and the source/destination 
address/ports and the editor (probably using the libnet stuff and the simulator 
tcpstack) creates a tcpdump file of what the transaction looks like as a 
tcpdump file ready for simulation with the option for the user to dig down 
and change header data in the packet if desired. I'll probably put this on the 
"poke at when I get time" list, because it is over kill for what we need right 
now but what we do need now will act as a base for such a project.
	I'll try and get some time to run gdb against 2.0.0g with the fraged
file and see if I can get some debug output for you.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada