On Thu, Jul 23, 2009 at 6:28 AM, Sake Blok<[email protected]> wrote: > Kevin, > > Yes, this is definitely worthy of a feature request. In fact, the developers > have discussed this option at Sharkfest in great depth. Please feel > comfortable to add it to the list. > > In general, there are many caveats in implementing anonimization. It should > be handled per protocol, taken into account that certain data can be > segmented across multiple frames. It can be compressed or > encapsulated. Certain lower layer data can be present in higher layer > protocols. So in the end, if it is implemented, it should be used with great > caution. A false sense of security is worse than having no security at all > (which of course can be disputed ;-)). > > As for masking IP addresses. Of course it is easy to alter the src and dst > ip addresses of packets, but what to do with the icmp unreachable messages. > And the port command of an FTP session? Or the X-Forwarded-For header in > HTTP? And should IP addresses be changed the same way on all protocol > levels? > > We really need this feature IMHO, but it is pretty complex to implement it > properly unfortunately. > > Cheers, > > > Sake > > PS Have a look at the bittwist "suite", it contains bittwiste which could > alter mac-addresses, ip-addresses, ports etc of packets, so that might suit > your needs, but be aware of the higher layers that might still contain the > things you were trying to mask (http://bittwist.sourceforge.net/).
Tcpreplay does this too. Sake is 100% right on target. One thing to keep in mind though is what is more sensitive: IP & MAC addresses or usernames & passwords? Personally I'd be more worried about clear text protocols like http, ftp and telnet exposing login information. Don't forget to edit DNS and HTTP/SIP Host header (if I know your hostname, I can just use DNS to find your IP address) too. Long story short, this topic comes up quite a bit on the tcpreplay-users list and I personally find it dangerous to assume any anonymization feature can make sensitive pcaps magically safe for sharing on pcapr.net or other public websites. Even if successful at anonymization, there's a good chance that the edits will break the protocol in question and render the data useless. Not saying Wireshark shouldn't do this- just that it should have a nice big disclaimer associated with it :) -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
