On Thu, Jul 23, 2009 at 6:28 AM, Sake Blok<sake@xxxxxxxxxx> 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
