openpacket-devel

[Openpacket-devel] OpenPacket.org RC1

[Richard B. <tao...@gm...>]

Thanks to even more excellent, all-volunteer work of our developer
Sharri Parsell, I am happy to notify you RC1 of OpenPacket.org is now
available at

http://beta.openpacket.org:8080/

Thank you to JJC of www.redsphereglobal.com for continuing to provide
free temporary hosting. We are working on a more permanent solution,
but if you have ideas now please let me know.

Please take a look and report feedback to the mailing list.

This site is considered RC1 quality. We plan to announce RC2 on 18
January, followed by a public RELEASE on 1 February.

If you are interested in assessing the security of the site, please
contact me directly. We can coordinate with Sharri and JJC to ensure
your discoveries do not catch us by surprise. We appreciate those of
you who did some XSS testing -- please try again and let us know what
you find.

Thank you,

Richard

Re: [Openpacket-devel] OpenPacket.org RC1

[Richard B. <tao...@gm...>]

On Jan 8, 2008 9:58 AM, James Pleger <jp...@gm...> wrote:
> Site is looking good! The only thing that I can say is that I think they
> forums are kind of lacking in features... I am not sure what moderators can
> see, but I can't edit my own posts, or message other users. I know it is all
> custom built, but you might want to research into a prebuilt forum system,
> and just hook into their login system.
>
> I still think it is coming along great :-)
>

Thanks James -- good feedback.

Richard

Re: [Openpacket-devel] OpenPacket.org RC1

[Richard B. <tao...@gm...>]

On Jan 8, 2008 10:12 AM, Jeff Lake <jl...@kc...> wrote:

> Nice to have the filesize limit listed on the upload page. I was having
> the devil's own time trying to upload a lpc file last month.
> JL
>
>

Hi Jeff,

I requested an increase to 10 MB as well.

Thank you,

Richard

Re: [Openpacket-devel] OpenPacket.org RC1

[Jeremy S. <st...@pa...>]

First off, let me congratulate the Openpacket team on this milestone!
I've enjoyed watching the site progress and mature over the past few
months. Openpacket is sure to enjoy success when it finally goes public.

I did stumble across a few minor areas which could use fixing up:

- The link to a user's profile from a forum's thread list is wrong. For
example, on http://beta.openpacket.org:8080/forum/show/3, from what I
can tell
http://beta.openpacket.org:8080/profile/showpublicprofile?userid=stretch
should be
http://beta.openpacket.org:8080/profile/public_profile?userid=stretch

- On a forum thread's page, the user's info appears incorrectly. For
example, on http://beta.openpacket.org:8080/post/showthread/12, it lists
my (stretch's) location and post count as "9".

- It would be nice to have a forum post preview feature.

- I remember this was discussed a while back, but can't remember how it
ended; is there any plan to add a confidentiality disclaimer on the
upload page?

- Might want to put a link to a capture's discussion thread (if any) on
the 'details' page.

- It would be really neat if the tshark analysis was done automatically
on the server side, though I'm not sure how practical that would be.

Just my $0.02. As always, keep up the great work! And don't hesitate to
ask the community for help.

Stretch

Richard Bejtlich wrote:
> Thanks to even more excellent, all-volunteer work of our developer
> Sharri Parsell, I am happy to notify you RC1 of OpenPacket.org is now
> available at
>
> http://beta.openpacket.org:8080/
>
> Thank you to JJC of www.redsphereglobal.com for continuing to provide
> free temporary hosting. We are working on a more permanent solution,
> but if you have ideas now please let me know.
>
> Please take a look and report feedback to the mailing list.
>
> This site is considered RC1 quality. We plan to announce RC2 on 18
> January, followed by a public RELEASE on 1 February.
>
> If you are interested in assessing the security of the site, please
> contact me directly. We can coordinate with Sharri and JJC to ensure
> your discoveries do not catch us by surprise. We appreciate those of
> you who did some XSS testing -- please try again and let us know what
> you find.
>
> Thank you,
>
> Richard
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>
>   

Re: [Openpacket-devel] OpenPacket.org RC1

[Richard B. <tao...@gm...>]

On Jan 8, 2008 10:31 AM, Jeremy Stretch <st...@pa...> wrote:
> First off, let me congratulate the Openpacket team on this milestone!
> I've enjoyed watching the site progress and mature over the past few
> months. Openpacket is sure to enjoy success when it finally goes public.
>
> I did stumble across a few minor areas which could use fixing up:
>
> - The link to a user's profile from a forum's thread list is wrong. For
> example, on http://beta.openpacket.org:8080/forum/show/3, from what I
> can tell
> http://beta.openpacket.org:8080/profile/showpublicprofile?userid=stretch
> should be
> http://beta.openpacket.org:8080/profile/public_profile?userid=stretch
>
> - On a forum thread's page, the user's info appears incorrectly. For
> example, on http://beta.openpacket.org:8080/post/showthread/12, it lists
> my (stretch's) location and post count as "9".
>
> - It would be nice to have a forum post preview feature.
>
> - I remember this was discussed a while back, but can't remember how it
> ended; is there any plan to add a confidentiality disclaimer on the
> upload page?
>
> - Might want to put a link to a capture's discussion thread (if any) on
> the 'details' page.
>
> - It would be really neat if the tshark analysis was done automatically
> on the server side, though I'm not sure how practical that would be.
>
> Just my $0.02. As always, keep up the great work! And don't hesitate to
> ask the community for help.
>
> Stretch
>

Stretch,

Thanks for all of your great feedback.

I just wanted to make one note: I do not like the idea of letting the
server provide Tshark output.  From a user standpoint I really want
it, but from a security standpoint I think it would be too big a
vulnerability.  There are too many protocol dissector vulnerabilities
announced with each release of Wireshark.  I'd rather let the user
deal with it than provide an easy avenue to exploit our server.

Sincerely,

Richard

Re: [Openpacket-devel] OpenPacket.org RC1

[James P. <jp...@gm...>]

On the other hand, you could get pcaps of the vulnerability :-)

I wouldn't mind running a host with a corerestore card that could run the
stuff in batches :/

On Jan 8, 2008 8:41 AM, Richard Bejtlich <tao...@gm...> wrote:

> On Jan 8, 2008 10:31 AM, Jeremy Stretch <st...@pa...> wrote:
> > First off, let me congratulate the Openpacket team on this milestone!
> > I've enjoyed watching the site progress and mature over the past few
> > months. Openpacket is sure to enjoy success when it finally goes public.
> >
> > I did stumble across a few minor areas which could use fixing up:
> >
> > - The link to a user's profile from a forum's thread list is wrong. For
> > example, on http://beta.openpacket.org:8080/forum/show/3, from what I
> > can tell
> > http://beta.openpacket.org:8080/profile/showpublicprofile?userid=stretch
> > should be
> > http://beta.openpacket.org:8080/profile/public_profile?userid=stretch
> >
> > - On a forum thread's page, the user's info appears incorrectly. For
> > example, on http://beta.openpacket.org:8080/post/showthread/12, it lists
> > my (stretch's) location and post count as "9".
> >
> > - It would be nice to have a forum post preview feature.
> >
> > - I remember this was discussed a while back, but can't remember how it
> > ended; is there any plan to add a confidentiality disclaimer on the
> > upload page?
> >
> > - Might want to put a link to a capture's discussion thread (if any) on
> > the 'details' page.
> >
> > - It would be really neat if the tshark analysis was done automatically
> > on the server side, though I'm not sure how practical that would be.
> >
> > Just my $0.02. As always, keep up the great work! And don't hesitate to
> > ask the community for help.
> >
> > Stretch
> >
>
> Stretch,
>
> Thanks for all of your great feedback.
>
> I just wanted to make one note: I do not like the idea of letting the
> server provide Tshark output.  From a user standpoint I really want
> it, but from a security standpoint I think it would be too big a
> vulnerability.  There are too many protocol dissector vulnerabilities
> announced with each release of Wireshark.  I'd rather let the user
> deal with it than provide an easy avenue to exploit our server.
>
> Sincerely,
>
> Richard
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>



-- 
James Pleger
p: 623.298.7966
e: jp...@gm...

Re: [Openpacket-devel] OpenPacket.org RC1

[CS L. <ge...@gm...>]

Hi all,

I agree no more, if you can provide with modified or stripped pcap, you
should have already have tshark in your own machine, openpacket shouldn't
handle those kind of job(avoid pcap analysis on the server as it will add
more loads to the server(imagine a lot of people run tshark at the same time
in the server and it would be like dos if the server can't handle it and you
can also generate traffics on the server without using the -n option) and we
all know dissector issues in wireshark imposing too much risks based on its
prior records.

I would be pleased to see it has normal functionalities such as download and
upload pcap and the discussion for certain pcap in forum, to me most of the
pcap should be modified or anonymized by the users itself and the server
shouldn't provide this kind of functionality.

Thanks

On Jan 8, 2008 11:41 PM, Richard Bejtlich <tao...@gm...> wrote:

> On Jan 8, 2008 10:31 AM, Jeremy Stretch <st...@pa...> wrote:
> > First off, let me congratulate the Openpacket team on this milestone!
> > I've enjoyed watching the site progress and mature over the past few
> > months. Openpacket is sure to enjoy success when it finally goes public.
> >
> > I did stumble across a few minor areas which could use fixing up:
> >
> > - The link to a user's profile from a forum's thread list is wrong. For
> > example, on http://beta.openpacket.org:8080/forum/show/3, from what I
> > can tell
> > http://beta.openpacket.org:8080/profile/showpublicprofile?userid=stretch
> > should be
> > http://beta.openpacket.org:8080/profile/public_profile?userid=stretch
> >
> > - On a forum thread's page, the user's info appears incorrectly. For
> > example, on http://beta.openpacket.org:8080/post/showthread/12, it lists
> > my (stretch's) location and post count as "9".
> >
> > - It would be nice to have a forum post preview feature.
> >
> > - I remember this was discussed a while back, but can't remember how it
> > ended; is there any plan to add a confidentiality disclaimer on the
> > upload page?
> >
> > - Might want to put a link to a capture's discussion thread (if any) on
> > the 'details' page.
> >
> > - It would be really neat if the tshark analysis was done automatically
> > on the server side, though I'm not sure how practical that would be.
> >
> > Just my $0.02. As always, keep up the great work! And don't hesitate to
> > ask the community for help.
> >
> > Stretch
> >
>
> Stretch,
>
> Thanks for all of your great feedback.
>
> I just wanted to make one note: I do not like the idea of letting the
> server provide Tshark output.  From a user standpoint I really want
> it, but from a security standpoint I think it would be too big a
> vulnerability.  There are too many protocol dissector vulnerabilities
> announced with each release of Wireshark.  I'd rather let the user
> deal with it than provide an easy avenue to exploit our server.
>
> Sincerely,
>
> Richard
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>



-- 
Best Regards,

CS Lee<geek00L[at]gmail.com>

http://geek00l.blogspot.com

Re: [Openpacket-devel] OpenPacket.org RC1

[James P. <jp...@gm...>]

I agree that it should be the users responsibility, however... To ease the
burden of doing this(for me, i would have to write a small shell script to
anonymize pcaps if I wanted to contribute a good deal of pcaps.

What I am trying to say is geeks are lazy, and you have to make it easy for
them to upload pcaps if you want to start getting a bunch of pcaps. I
believe that it is more of a usability feature than anything. ;-)

I have no problem running the anonymization on a box that I can run at home.
I can create a p2p vpn between the server and a box at home and run the
anonymization/tshark stuff on that box which will be isolated... It isn't a
big deal to run it off a different box.

On Jan 8, 2008 9:09 AM, CS Lee <ge...@gm...> wrote:

> Hi all,
>
> I agree no more, if you can provide with modified or stripped pcap, you
> should have already have tshark in your own machine, openpacket shouldn't
> handle those kind of job(avoid pcap analysis on the server as it will add
> more loads to the server(imagine a lot of people run tshark at the same time
> in the server and it would be like dos if the server can't handle it and you
> can also generate traffics on the server without using the -n option) and we
> all know dissector issues in wireshark imposing too much risks based on its
> prior records.
>
> I would be pleased to see it has normal functionalities such as download
> and upload pcap and the discussion for certain pcap in forum, to me most of
> the pcap should be modified or anonymized by the users itself and the server
> shouldn't provide this kind of functionality.
>
> Thanks
>
>
> On Jan 8, 2008 11:41 PM, Richard Bejtlich <tao...@gm...> wrote:
>
> > On Jan 8, 2008 10:31 AM, Jeremy Stretch <st...@pa...> wrote:
> > > First off, let me congratulate the Openpacket team on this milestone!
> > > I've enjoyed watching the site progress and mature over the past few
> > > months. Openpacket is sure to enjoy success when it finally goes
> > public.
> > >
> > > I did stumble across a few minor areas which could use fixing up:
> > >
> > > - The link to a user's profile from a forum's thread list is wrong.
> > For
> > > example, on http://beta.openpacket.org:8080/forum/show/3 , from what I
> > > can tell
> > >
> > http://beta.openpacket.org:8080/profile/showpublicprofile?userid=stretch
> > > should be
> > > http://beta.openpacket.org:8080/profile/public_profile?userid=stretch
> > >
> > > - On a forum thread's page, the user's info appears incorrectly. For
> > > example, on http://beta.openpacket.org:8080/post/showthread/12, it
> > lists
> > > my (stretch's) location and post count as "9".
> > >
> > > - It would be nice to have a forum post preview feature.
> > >
> > > - I remember this was discussed a while back, but can't remember how
> > it
> > > ended; is there any plan to add a confidentiality disclaimer on the
> > > upload page?
> > >
> > > - Might want to put a link to a capture's discussion thread (if any)
> > on
> > > the 'details' page.
> > >
> > > - It would be really neat if the tshark analysis was done
> > automatically
> > > on the server side, though I'm not sure how practical that would be.
> > >
> > > Just my $0.02. As always, keep up the great work! And don't hesitate
> > to
> > > ask the community for help.
> > >
> > > Stretch
> > >
> >
> > Stretch,
> >
> > Thanks for all of your great feedback.
> >
> > I just wanted to make one note: I do not like the idea of letting the
> > server provide Tshark output.  From a user standpoint I really want
> > it, but from a security standpoint I think it would be too big a
> > vulnerability.  There are too many protocol dissector vulnerabilities
> > announced with each release of Wireshark.  I'd rather let the user
> > deal with it than provide an easy avenue to exploit our server.
> >
> > Sincerely,
> >
> > Richard
> >
> >
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> >
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________
> > Openpacket-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openpacket-devel
> >
>
>
>
> --
> Best Regards,
>
> CS Lee<geek00L[at]gmail.com>
>
> http://geek00l.blogspot.com
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>
>

Re: [Openpacket-devel] OpenPacket.org RC1

[Richard B. <tao...@gm...>]

On Jan 8, 2008 11:19 AM, James Pleger <jp...@gm...> wrote:
> I agree that it should be the users responsibility, however... To ease the
> burden of doing this(for me, i would have to write a small shell script to
> anonymize pcaps if I wanted to contribute a good deal of pcaps.
>

Regarding anonymization -- I will prepare (or if someone else beats me
to it, please do) a guide for anonmizing traces and links and demos to
existing software.  Please keep in mind I intend to follow the
guidelines I posted here:

http://openpacket.sourceforge.net/openpacket_req_doc_draft_21jul06.pdf

OpenPacket.org moderators will not be responsible for anonymizing
traces.  It's too much of a burden in many ways.

Thank you,

Richard

Re: [Openpacket-devel] OpenPacket.org RC1

[CS L. <ge...@gm...>]

Hi James,

What do you mean by writing shell script to anonymize pcaps you want to
contribute?

Good point where it should be users responsibility to anonymize pcap is so
that the moderators won't be suspected if anything happen. Certain packet
attributes should be anonymized such as -

Link Layer: source and destination mac address
Network Layer: source and destination ip address
Transport Layer: usually none, icmp message maybe
Payload: dependent

If the payload contents confidential information then it should be
anonymized or else it should be fine. To get most of the job done, I have
covered them here -

http://geek00l.blogspot.com/search?q=bittwiste

I think for link layer address modification, the latest bittwiste can do it
very well now. For payload wise, you can use bittwiste too or if you prefer
gui - netdude and some other tools such as tcpreplay.

If you have already tried out the rawpacket HeX liveCD, we have all the
tools categorized under Pcap-Editor where you can use it.

If Richard thinks it is necessary to write up tutorial or short guide for
pcap anonymization, i can take it by rearranging my writeup in blog or maybe
we can do the screencast for that particular purpose.

Cheers ;]

On Jan 9, 2008 1:23 AM, Richard Bejtlich <tao...@gm...> wrote:

> On Jan 8, 2008 11:19 AM, James Pleger <jp...@gm...> wrote:
> > I agree that it should be the users responsibility, however... To ease
> the
> > burden of doing this(for me, i would have to write a small shell script
> to
> > anonymize pcaps if I wanted to contribute a good deal of pcaps.
> >
>
> Regarding anonymization -- I will prepare (or if someone else beats me
> to it, please do) a guide for anonmizing traces and links and demos to
> existing software.  Please keep in mind I intend to follow the
> guidelines I posted here:
>
> http://openpacket.sourceforge.net/openpacket_req_doc_draft_21jul06.pdf
>
> OpenPacket.org moderators will not be responsible for anonymizing
> traces.  It's too much of a burden in many ways.
>
> Thank you,
>
> Richard
>



-- 
Best Regards,

CS Lee<geek00L[at]gmail.com>

http://geek00l.blogspot.com

Re: [Openpacket-devel] OpenPacket.org RC1

[James P. <jp...@gm...>]

Just writing a small shell script that would call the correct tcpreplay
functions to anonymize pcaps... It would be quite simple.

An example of the commands in tcpreplay to anonymize a pcap are located at:
http://sheeple.us/?p=38

On Jan 8, 2008 6:00 PM, CS Lee <ge...@gm...> wrote:

> Hi James,
>
> What do you mean by writing shell script to anonymize pcaps you want to
> contribute?
>
> Good point where it should be users responsibility to anonymize pcap is so
> that the moderators won't be suspected if anything happen. Certain packet
> attributes should be anonymized such as -
>
> Link Layer: source and destination mac address
> Network Layer: source and destination ip address
> Transport Layer: usually none, icmp message maybe
> Payload: dependent
>
> If the payload contents confidential information then it should be
> anonymized or else it should be fine. To get most of the job done, I have
> covered them here -
>
> http://geek00l.blogspot.com/search?q=bittwiste
>
> I think for link layer address modification, the latest bittwiste can do
> it very well now. For payload wise, you can use bittwiste too or if you
> prefer gui - netdude and some other tools such as tcpreplay.
>
> If you have already tried out the rawpacket HeX liveCD, we have all the
> tools categorized under Pcap-Editor where you can use it.
>
> If Richard thinks it is necessary to write up tutorial or short guide for
> pcap anonymization, i can take it by rearranging my writeup in blog or maybe
> we can do the screencast for that particular purpose.
>
> Cheers ;]
>
>
> On Jan 9, 2008 1:23 AM, Richard Bejtlich <tao...@gm...> wrote:
>
> > On Jan 8, 2008 11:19 AM, James Pleger <jp...@gm...> wrote:
> > > I agree that it should be the users responsibility, however... To ease
> > the
> > > burden of doing this(for me, i would have to write a small shell
> > script to
> > > anonymize pcaps if I wanted to contribute a good deal of pcaps.
> > >
> >
> > Regarding anonymization -- I will prepare (or if someone else beats me
> > to it, please do) a guide for anonmizing traces and links and demos to
> > existing software.  Please keep in mind I intend to follow the
> > guidelines I posted here:
> >
> > http://openpacket.sourceforge.net/openpacket_req_doc_draft_21jul06.pdf
> >
> > OpenPacket.org moderators will not be responsible for anonymizing
> > traces.  It's too much of a burden in many ways.
> >
> > Thank you,
> >
> > Richard
> >
>
>
>
> --
> Best Regards,
>
> CS Lee<geek00L[at]gmail.com>
>
> http://geek00l.blogspot.com
>



-- 
James Pleger
p: 623.298.7966
e: jp...@gm...

Re: [Openpacket-devel] OpenPacket.org RC1

[Aaron T. <syn...@gm...>]

Just a few comments off the top of my head since I've given a lot of
thought to editing pcap files:

1) Why would you anonymize the MAC addresses?  Do people really care
if a Apple host talked to an Intel card?  I would argue if you are
this concerned with data leak, you're not going to be publishing
pcap's of your traffic on a public website anyways.

2) Rewriting IP addresses is full of fun problems.  Things like
multicast/subnet broadcasts (non-255.255.255.255) mean you can't aways
rewrite dest addresses.  DHCP, Bootp shouldn't rewrite source
addresses.  Then there's all those fun protocols which can/will embed
your IP address in the payload (FTP port command, SIP, HTTP Host
Header, etc) in various formats.   It's easy to screw this up and make
the sample pcap useless because the wrong IP was put in the
application layer.

3) A lot of these tools only deal with DLT_EN10MB encapsulated pcaps
(aka Ethernet).  Once you start dealing with more interesting
protocols like HDLC and the 100+ others that libpcap supports good
luck.  Note: tcpreplay/tcprewrite supports a number of the more common
ones, but is hardly complete.

4) I'm not aware of any tools which can in an automated way properly
handle Layer7 anonymization.  I suppose you could open each packet in
NetDude and hack things manually, but l doubt anyone is that motivated
not to mention being error prone.

5) Anyone relying on anonymizing their pcap before they post it to
keep them safe is a fool.  If you care about security, the only valid
solution is generate the network traffic on an air-gapped lab network
or a "throw away" test network.   I know I wouldn't risk my network or
my job on a anonymizing tool which may or may not work.

In conclusion: Any script which attempts to anonymize pcaps won't
properly protect from a data leak and is just as likely to break the
protocol to make the pcap useless.


-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.  -- Benjamin Franklin


On Jan 8, 2008 5:00 PM, CS Lee <ge...@gm...> wrote:
> Hi James,
>
> What do you mean by writing shell script to anonymize pcaps you want to
> contribute?
>
> Good point where it should be users responsibility to anonymize pcap is so
> that the moderators won't be suspected if anything happen. Certain packet
> attributes should be anonymized such as -
>
> Link Layer: source and destination mac address
> Network Layer: source and destination ip address
> Transport Layer: usually none, icmp message maybe
> Payload: dependent
>
> If the payload contents confidential information then it should be
> anonymized or else it should be fine. To get most of the job done, I have
> covered them here -
>
> http://geek00l.blogspot.com/search?q=bittwiste
>
> I think for link layer address modification, the latest bittwiste can do it
> very well now. For payload wise, you can use bittwiste too or if you prefer
> gui - netdude and some other tools such as tcpreplay.
>
> If you have already tried out the rawpacket HeX liveCD, we have all the
> tools categorized under Pcap-Editor where you can use it.
>
> If Richard thinks it is necessary to write up tutorial or short guide for
> pcap anonymization, i can take it by rearranging my writeup in blog or maybe
> we can do the screencast for that particular purpose.
>
> Cheers ;]

Re: [Openpacket-devel] OpenPacket.org RC1

[James P. <jp...@gm...>]

Sorry to quote, but:
"OpenPacket.org moderators will not be responsible for anonymizing traces.
 It's too much of a burden in many ways."

I think the discussion about anonymization is kind of dead and while you
have a bunch of very good points, it is up to the user to determine what
kind of anonymization of the pcaps... I think a disclaimer on the site is
sufficient, and I was merely throwing it out there as a "Nifty feature" type
of request. I think that a howto that is well written would work great as a
substitute to this type of functionality. I may throw together a small
script that could anonymize things inside the IP header, for myself and any
other people that are interested in it. I personally don't care about
anything in layer 7 :P

Thanks,
James

On Jan 8, 2008 7:33 PM, Aaron Turner <syn...@gm...> wrote:

> Just a few comments off the top of my head since I've given a lot of
> thought to editing pcap files:
>
> 1) Why would you anonymize the MAC addresses?  Do people really care
> if a Apple host talked to an Intel card?  I would argue if you are
> this concerned with data leak, you're not going to be publishing
> pcap's of your traffic on a public website anyways.
>
> 2) Rewriting IP addresses is full of fun problems.  Things like
> multicast/subnet broadcasts (non-255.255.255.255) mean you can't aways
> rewrite dest addresses.  DHCP, Bootp shouldn't rewrite source
> addresses.  Then there's all those fun protocols which can/will embed
> your IP address in the payload (FTP port command, SIP, HTTP Host
> Header, etc) in various formats.   It's easy to screw this up and make
> the sample pcap useless because the wrong IP was put in the
> application layer.
>
> 3) A lot of these tools only deal with DLT_EN10MB encapsulated pcaps
> (aka Ethernet).  Once you start dealing with more interesting
> protocols like HDLC and the 100+ others that libpcap supports good
> luck.  Note: tcpreplay/tcprewrite supports a number of the more common
> ones, but is hardly complete.
>
> 4) I'm not aware of any tools which can in an automated way properly
> handle Layer7 anonymization.  I suppose you could open each packet in
> NetDude and hack things manually, but l doubt anyone is that motivated
> not to mention being error prone.
>
> 5) Anyone relying on anonymizing their pcap before they post it to
> keep them safe is a fool.  If you care about security, the only valid
> solution is generate the network traffic on an air-gapped lab network
> or a "throw away" test network.   I know I wouldn't risk my network or
> my job on a anonymizing tool which may or may not work.
>
> In conclusion: Any script which attempts to anonymize pcaps won't
> properly protect from a data leak and is just as likely to break the
> protocol to make the pcap useless.
>
>
> --
> Aaron Turner
> http://synfin.net/
> http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix
> They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety.  -- Benjamin Franklin
>
>
> On Jan 8, 2008 5:00 PM, CS Lee <ge...@gm...> wrote:
> > Hi James,
> >
> > What do you mean by writing shell script to anonymize pcaps you want to
> > contribute?
> >
> > Good point where it should be users responsibility to anonymize pcap is
> so
> > that the moderators won't be suspected if anything happen. Certain
> packet
> > attributes should be anonymized such as -
> >
> > Link Layer: source and destination mac address
> > Network Layer: source and destination ip address
> > Transport Layer: usually none, icmp message maybe
> > Payload: dependent
> >
> > If the payload contents confidential information then it should be
> > anonymized or else it should be fine. To get most of the job done, I
> have
> > covered them here -
> >
> > http://geek00l.blogspot.com/search?q=bittwiste
> >
> > I think for link layer address modification, the latest bittwiste can do
> it
> > very well now. For payload wise, you can use bittwiste too or if you
> prefer
> > gui - netdude and some other tools such as tcpreplay.
> >
> > If you have already tried out the rawpacket HeX liveCD, we have all the
> > tools categorized under Pcap-Editor where you can use it.
> >
> > If Richard thinks it is necessary to write up tutorial or short guide
> for
> > pcap anonymization, i can take it by rearranging my writeup in blog or
> maybe
> > we can do the screencast for that particular purpose.
> >
> > Cheers ;]
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>

Re: [Openpacket-devel] OpenPacket.org RC1

[Richard B. <tao...@gm...>]

On Jan 8, 2008 9:49 PM, James Pleger <jp...@gm...> wrote:
> Sorry to quote, but:
>
> "OpenPacket.org moderators will not be responsible for anonymizing traces.
> It's too much of a burden in many ways."
>
> I think the discussion about anonymization is kind of dead and while you
> have a bunch of very good points, it is up to the user to determine what
> kind of anonymization of the pcaps... I think a disclaimer on the site is
> sufficient, and I was merely throwing it out there as a "Nifty feature" type
> of request. I think that a howto that is well written would work great as a
> substitute to this type of functionality. I may throw together a small
> script that could anonymize things inside the IP header, for myself and any
> other people that are interested in it. I personally don't care about
> anything in layer 7 :P
>
>

Thanks to everyone for their thoughts.  I agree with Aaron's points.
However, I see James' point too.  If someone wants to upload a trace
that has been anonymized to whatever degree they like, that is fine by
me.  I recommend reading the Trace Restrictions section here:

http://openpacket.sourceforge.net/openpacket_req_doc_draft_21jul06.pdf

I should have said that scrubbing was OPTIONAL, not a way to "clean"
sensitive data so it could be published.  I don't think I phrased what
I meant very well:

"If necessary, traffic captured on production networks will be
scrubbed to obscure any identifying characteristics, such as source
and/or destination IP addresses.  OpenPacket.org reserves the right to
make these scrubbing decisions and actions."

This is the overriding principle:

"The traffic does not contain any proprietary or sensitive information
that the submitting enterprise would not want published."

OpenPacket.org moderators absolutely will NOT publish traces that,
using our best judgment, contain data we feel should not be published.
 If we receive legitimate complaints the trace will be removed
immediately.

If you operate a private test lab and capture worm traffic or whatever
else, I don't see the need to attempt obfuscation.

If you operate a honeynet, and you want to try to remove information
identifying your honeynet IPs, scrub away.

If you want to rip out all layer 7 data, that's fine.  Some people
might like it, others not.

If you really want to provide production traffic that contains your
users IM conversations, our moderators will reject it.

Thank you,

Richard

Re: [Openpacket-devel] OpenPacket.org RC1

[Jeff L. <jl...@kc...>]

Richard Bejtlich wrote:
  > OpenPacket.org moderators absolutely will NOT publish traces that,
> using our best judgment, contain data we feel should not be published.
>  If we receive legitimate complaints the trace will be removed
> immediately.
>=20

So will the moderators have to parse through every 10MB pcap file that=20
might have some guy's myspace password buried in there ? That sounds=20
like a lot of work for the mods.
J

Re: [Openpacket-devel] OpenPacket.org RC1

[Andrew H. <and...@gm...>]

Might I suggest that the script replace the payload with a simple ASCII
string of: "Payload withheld at the request of the submitter"
(or something similar) :)

On 08/01/2008, CS Lee <ge...@gm...> wrote:
>
> Hi James,
>
> What do you mean by writing shell script to anonymize pcaps you want to
> contribute?
>
> Good point where it should be users responsibility to anonymize pcap is so
> that the moderators won't be suspected if anything happen. Certain packet
> attributes should be anonymized such as -
>
> Link Layer: source and destination mac address
> Network Layer: source and destination ip address
> Transport Layer: usually none, icmp message maybe
> Payload: dependent
>
> If the payload contents confidential information then it should be
> anonymized or else it should be fine. To get most of the job done, I have
> covered them here -
>
> http://geek00l.blogspot.com/search?q=bittwiste
>
> I think for link layer address modification, the latest bittwiste can do
> it very well now. For payload wise, you can use bittwiste too or if you
> prefer gui - netdude and some other tools such as tcpreplay.
>
> If you have already tried out the rawpacket HeX liveCD, we have all the
> tools categorized under Pcap-Editor where you can use it.
>
> If Richard thinks it is necessary to write up tutorial or short guide for
> pcap anonymization, i can take it by rearranging my writeup in blog or maybe
> we can do the screencast for that particular purpose.
>
> Cheers ;]
>
> On Jan 9, 2008 1:23 AM, Richard Bejtlich <tao...@gm...> wrote:
>
> > On Jan 8, 2008 11:19 AM, James Pleger <jp...@gm...> wrote:
> > > I agree that it should be the users responsibility, however... To ease
> > the
> > > burden of doing this(for me, i would have to write a small shell
> > script to
> > > anonymize pcaps if I wanted to contribute a good deal of pcaps.
> > >
> >
> >
> > Regarding anonymization -- I will prepare (or if someone else beats me
> > to it, please do) a guide for anonmizing traces and links and demos to
> > existing software.  Please keep in mind I intend to follow the
> > guidelines I posted here:
> >
> > http://openpacket.sourceforge.net/openpacket_req_doc_draft_21jul06.pdf
> >
> > OpenPacket.org moderators will not be responsible for anonymizing
> > traces.  It's too much of a burden in many ways.
> >
> > Thank you,
> >
> > Richard
> >
>
>
>
> --
> Best Regards,
>
> CS Lee<geek00L[at]gmail.com>
>
> http://geek00l.blogspot.com
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>
>


-- 
Andrew Hay
blog: http://www.andrewhay.ca
email: andrewsmhay || at || gmail.com
LinkedIn Profile: http://www.linkedin.com/in/andrewhay

Re: [Openpacket-devel] OpenPacket.org RC1

[Aaron T. <syn...@gm...>]

On Jan 8, 2008 6:07 PM, Andrew Hay <and...@gm...> wrote:
> Might I suggest that the script replace the payload with a simple ASCII
> string of: "Payload withheld at the request of the submitter"
>
> (or something similar) :)

If you're going to do that, don't bother submitting your pcap.   The
last thing I want to do is download a BGP session and get nothing but
a TCP 3way handshake and then worthless ASCII garbage saying the
submitter didn't want me to see what BGP looks like.


-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.  -- Benjamin Franklin

Re: [Openpacket-devel] OpenPacket.org RC1

[Jeremy S. <st...@pa...>]

I think (and correct me if I'm wrong) it's simply a best-effort
approach. No one can expect a volunteer moderator to account for every
bit in a capture, but some general assumptions can be made at first
glance regarding the risk associated with publishing a capture. This
*courtesy* coupled with a solid disclaimer of liability creates a
comfortable balance of open atmosphere and privacy.

Stretch

Jeff Lake wrote:
> Richard Bejtlich wrote:
>  > OpenPacket.org moderators absolutely will NOT publish traces that,
>> using our best judgment, contain data we feel should not be published.
>>  If we receive legitimate complaints the trace will be removed
>> immediately.
>>
>
> So will the moderators have to parse through every 10MB pcap file that
> might have some guy's myspace password buried in there ? That sounds
> like a lot of work for the mods.
> J
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ------------------------------------------------------------------------
>
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>   

Re: [Openpacket-devel] OpenPacket.org RC1

[Richard B. <tao...@gm...>]

On Jan 9, 2008 7:30 AM, Jeremy Stretch <st...@pa...> wrote:
> I think (and correct me if I'm wrong) it's simply a best-effort
> approach. No one can expect a volunteer moderator to account for every
> bit in a capture, but some general assumptions can be made at first
> glance regarding the risk associated with publishing a capture. This
> *courtesy* coupled with a solid disclaimer of liability creates a
> comfortable balance of open atmosphere and privacy.
>
> Stretch

Stretch,

That's exactly right.

Richard