openpacket-devel — OpenPacket development list

[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

[Openpacket-devel] OpenPacket.org casual browsing

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

Hi Sharri,

I was doing some casual browsing of OpenPacket.org and encountered a few issues:

1. From

http://beta.openpacket.org:8080/post/showthread/6

clicking on Latest Posts

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

produced

We're sorry, but something went wrong.

We've been notified about this issue and we'll take a look at it shortly.

2. On the same page, clicking on Most Viewed

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

produced the same error.

3. On the same page, clicking on Search

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

produced

The page you were looking for doesn't exist.

You may have mistyped the address or the page may have moved.

4. When I post a reply to a Forum message, I see this warning:

Note:  These forums are unmoderated but any posts deemed offensive
will be promptly removed. Thank you for your cooperation.

I thought the Forum Manager link in the Admin Menu might do it

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

but I got this error:

The page you were looking for doesn't exist.

You may have mistyped the address or the page may have moved.

5. It looks like the user registration process is vulnerable to XSS.
I noticed that when visiting the Manage Users link at

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

I got two results indicating XSS:

  <tr>
    <td><ScRiPt

>alert(831501365);</ScRiPt></td>
    <td>111...@ad... 111...@ad...</td>
    <td>111...@ad...</td>
    <td>Registered User</td>
    <td><a href="/user_manager/edit/22">Edit</a></td>

    <td><a href="/user_manager/destroy/22" onclick="if (confirm('Are
you sure?')) { var f = document.createElement('form'); f.style.display
= 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action
= this.href;f.submit(); };return false;">Destroy</a></td>
  </tr>

and

  <tr>
    <td>111...@ad...</td>
    <td>111...@ad... 111...@ad...</td>
    <td><ScRiPt

>alert(1651137805);</ScRiPt></td>

    <td>Registered User</td>
    <td><a href="/user_manager/edit/23">Edit</a></td>
    <td><a href="/user_manager/destroy/23" onclick="if (confirm('Are
you sure?')) { var f = document.createElement('form'); f.style.display
= 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action
= this.href;f.submit(); };return false;">Destroy</a></td>
  </tr>

6. I tried uploading a trace with DNS traffic to the capture repo.  I
got this error:

4 errors prohibited this capture from being saved

There were problems with the following fields:

    * Content type can't be blank
    * Size is not included in the list
    * Size can't be blank
    * Filename can't be blank

I provided this for the Tshark field:

===================================================================
Protocol Hierarchy Statistics
Filter: frame

frame                                    frames:6 bytes:612
  eth                                    frames:6 bytes:612
    ip                                   frames:6 bytes:612
      udp                                frames:6 bytes:612
        dns                              frames:6 bytes:612
===================================================================

I left the tags blank.  Can we have the tags auto-populate based on
the results of the Tshark output?

Thanks a lot Sharri!

Sincerely,

Richard

Re: [Openpacket-devel] Packet repository

[JJ C. <cum...@gm...>]

Jeff,

Please try a pcap capture and let me know what you see.

JJC

On Nov 15, 2007 12:57 PM, Jeff Lake <jl...@kc...> wrote:
> Should I be able to upload a packet capture? I am getting this:
>
> 1 error prohibited this capture from being saved
>
> There were problems with the following fields:
>
>     * Size is not included in the list
>
> JL
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>
>

[Openpacket-devel] Packet repository

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

Should I be able to upload a packet capture? I am getting this:

1 error prohibited this capture from being saved

There were problems with the following fields:

    * Size is not included in the list

JL

Re: [Openpacket-devel] New Beta Site Live

[JJ C. <cum...@gm...>]

I think that it's important to have some legal verbiage that indemnifies
openpacket.org...of course that bridge can be crossed when the rubber hits
the road.  As to removal of suspect material, could be something as simple
as a link within a registered account holders private area on the site, or a
link in an auto-response email post-uploading...

Personally I am more concerned about sensitive material over copyrighted
material, the standards such as PII, PCI etc....

As to something such as terms of use or some legal verbiage, I have a good
attorney friend that I could hook you up with, Richard, to answer any
questions etc...

JJC

On 10/17/07, David J. Bianco <da...@vo...> wrote:
>
> I definitely agree about the removal policy.  I also suggest that we
> make the user re-affirm that they have the right to post the traffic and
> that they agree to indemnify openpacket against any possible claims
> by third parties related to that trace.  If we can have those, then I
> think we're in pretty good shape.
>
> Personally, I don't think we should get too hung up on inventing problems
> for ourselves yet, though it's good that we have a plan for how to deal
> with this upfront.
>
>         David
>
> Richard Bejtlich wrote:
> > On 10/16/07, Tim Furlong <fu...@cc...> wrote:
> >> A good analogy might be the sites like YouTube that host user-submitted
> >> content and the posting of copyrighted material (and, to a lesser
> extent,
> >> private information).  So far, they seem to be getting away with just
> having
> >> mechanisms for copyright holders to request that the site remove their
> >> material - my lay impression is that they have not been successfully
> sued
> >> for damages yet.
> >>
> >
> > This is the right model, I think.  I also like the idea of adding a
> > "request removal" to each trace instead of expecting someone to send
> > an email.  If we receive a removal request that appears legitimate, I
> > will not hesitate to remove the trace.
> >
> > Even with these restrictions I think we could have a useful site!
> >
> > Richard
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Openpacket-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>

Re: [Openpacket-devel] New Beta Site Live

[David J. B. <da...@vo...>]

I definitely agree about the removal policy.  I also suggest that we
make the user re-affirm that they have the right to post the traffic and
that they agree to indemnify openpacket against any possible claims
by third parties related to that trace.  If we can have those, then I
think we're in pretty good shape.

Personally, I don't think we should get too hung up on inventing problems
for ourselves yet, though it's good that we have a plan for how to deal
with this upfront.

	David

Richard Bejtlich wrote:
> On 10/16/07, Tim Furlong <fu...@cc...> wrote:
>> A good analogy might be the sites like YouTube that host user-submitted
>> content and the posting of copyrighted material (and, to a lesser extent,
>> private information).  So far, they seem to be getting away with just having
>> mechanisms for copyright holders to request that the site remove their
>> material - my lay impression is that they have not been successfully sued
>> for damages yet.
>>
> 
> This is the right model, I think.  I also like the idea of adding a
> "request removal" to each trace instead of expecting someone to send
> an email.  If we receive a removal request that appears legitimate, I
> will not hesitate to remove the trace.
> 
> Even with these restrictions I think we could have a useful site!
> 
> Richard
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel

Re: [Openpacket-devel] New Beta Site Live

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

I'm no lawyer, however, the law appears to be on our side in this instance.

A lesser-known provision of the Digital Millennium Copyright Act (DMCA) 
called the Online Copyright Infringement Liability Limitation Act 
provides safe harbor for online service providers (such as ISPs and 
websites) from prosecution in the event copyrighted material is uploaded 
by a third party.

 From Wikipedia:

"DMCA Title II, the Online Copyright Infringement Liability Limitation 
Act 
<http://en.wikipedia.org/wiki/Online_Copyright_Infringement_Liability_Limitation_Act> 
("OCILLA") creates a safe harbor 
<http://en.wikipedia.org/wiki/Safe_harbor> for online service providers 
(OSPs, including ISPs) against copyright liability if they adhere to and 
qualify for certain prescribed safe harbor guidelines and promptly block 
access to allegedly infringing material (or remove such material from 
their systems) if they receive a notification claiming infringement from 
a copyright holder or the copyright holder's agent. OCILLA also includes 
a counter-notification provision that offers OSPs a safe harbor from 
liability to their users, if the material upon notice from such users 
claiming that the material in question is not, in fact, infringing. 
OCILLA also provides for subpoenas 
<http://en.wikipedia.org/wiki/Subpoena> to OSPs to provide their users' 
identity."

More at 
http://en.wikipedia.org/wiki/Online_Copyright_Infringement_Liability_Limitation_Act

If OpenPacket abides by the terms set forth in OCILLA, we should be 
absolved from responsibility for any suspected copyright infringement, 
assuming that any subpoenas received are promptly addressed. 
Furthermore, providing an easily accessible, off-the-record system for 
removing uploaded captures should greatly reduce the likelihood of being 
faced with legal action in the first place.

Granted, I don't know how or whether this applies beyond copyright law 
(for example, captures containing social security numbers or similar 
personal data), but it's a start.

Whether or not moderators take any initiative to check for private data 
in submitted captures needs to be explicitly stated. Personally I think 
it's most practical to take a completely hands-off approach unless a 
complaint is issued by an end user. In any case, users must be forced to 
acknowledge OpenPacket assumes zero responsibility for uploaded content.

Stretch

Richard Bejtlich wrote:
> On 10/16/07, Tim Furlong <fu...@cc...> wrote:
>   
>> A good analogy might be the sites like YouTube that host user-submitted
>> content and the posting of copyrighted material (and, to a lesser extent,
>> private information).  So far, they seem to be getting away with just having
>> mechanisms for copyright holders to request that the site remove their
>> material - my lay impression is that they have not been successfully sued
>> for damages yet.
>>
>>     
>
> This is the right model, I think.  I also like the idea of adding a
> "request removal" to each trace instead of expecting someone to send
> an email.  If we receive a removal request that appears legitimate, I
> will not hesitate to remove the trace.
>
> Even with these restrictions I think we could have a useful site!
>
> Richard
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>
>   

Re: [Openpacket-devel] New Beta Site Live

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

What might be better would be to "Report Abuse" or something similar,
then allowing to put "Copyrighted Materials", "Sensitive Data" or
something.

It was more of a feature request, as to helping anonymize just the ip
headers to rfc1918 or something similar, and allowing for expansion
into that. My opinion is anything after the IP headers are free game,
and should be posted... unmodified. My opinion is that if someone
uploads a pcap... it is their responsibility for anonymizing the
traffic. I think the feature to anonymize the ip header(source and
destination) would be a real timesaver for someone like me who might
be uploading lots of malicious pcaps, and I just need to anonymize src
and destination.

Just my 2 cents :)

On 10/16/07, Richard Bejtlich <tao...@gm...> wrote:
> On 10/16/07, Tim Furlong <fu...@cc...> wrote:
> >
> > A good analogy might be the sites like YouTube that host user-submitted
> > content and the posting of copyrighted material (and, to a lesser extent,
> > private information).  So far, they seem to be getting away with just having
> > mechanisms for copyright holders to request that the site remove their
> > material - my lay impression is that they have not been successfully sued
> > for damages yet.
> >
>
> This is the right model, I think.  I also like the idea of adding a
> "request removal" to each trace instead of expecting someone to send
> an email.  If we receive a removal request that appears legitimate, I
> will not hesitate to remove the trace.
>
> Even with these restrictions I think we could have a useful site!
>
> Richard
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> 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] New Beta Site Live

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

On 10/16/07, Tim Furlong <fu...@cc...> wrote:
>
> A good analogy might be the sites like YouTube that host user-submitted
> content and the posting of copyrighted material (and, to a lesser extent,
> private information).  So far, they seem to be getting away with just having
> mechanisms for copyright holders to request that the site remove their
> material - my lay impression is that they have not been successfully sued
> for damages yet.
>

This is the right model, I think.  I also like the idea of adding a
"request removal" to each trace instead of expecting someone to send
an email.  If we receive a removal request that appears legitimate, I
will not hesitate to remove the trace.

Even with these restrictions I think we could have a useful site!

Richard

[Openpacket-devel] New Beta Site Live

[Tim F. <fu...@cc...>]

On 10/16/07, Richard Bejtlich <tao...@gm...> wrote:
>
> On 10/16/07, David J. Bianco <da...@vo...> wrote:
> >
> > To me, the big worry is that an OpenPacket user will upload a pcap
> > with someone *else's* information in it.  It's hard to come up with a
> > TOS that releases you from liability when the injured party is not
> > bound by the TOS.
> >
> > Or maybe it's not.  I'm no lawyer.  But surely some other sites
> (Wireshark,
> > perhaps) must have already dealt with this issue.
> >
> >         David
> >
> >
>
> Hi David,
>
> That's a really good point.
>
> Re: other sites -- they appear to have ignored the issue.  Places like
>
> http://www.packet-level.com/traces/index.htm
>
> seem to host all lab-generated content.
>
> Others like
>
> http://wiki.wireshark.org/SampleCaptures
>
> just ignore privacy concerns, or at least they don't say how they
> address those concerns.
>
> Richard


Hi folks,

A good analogy might be the sites like YouTube that host user-submitted
content and the posting of copyrighted material (and, to a lesser extent,
private information).  So far, they seem to be getting away with just
having mechanisms for copyright holders to request that the site remove
their material - my lay impression is that they have not been successfully
sued for damages yet.

An interesting case to follow, from the perspective of OpenPacket.org, might
be the family that was beaten by gatecrashers after details of a house party
were posted to YouTube
(http://www.reuters.com/article/oddlyEnoughNews/idUSL1249768320071012).
I don't think anyone is pursuing action against YouTube yet, or if they
will, but it might generate some discussion about the responsibility of
YouTube, which might turn up some salient information on the applicable
laws.  It seems to be the most closely analogous example to what we're
worried about.

-Tim

-- 
Tim Furlong
tim...@gm...

Re: [Openpacket-devel] New Beta Site Live

[Richard H. F. <rfi...@fi...>]

On Tue, 16 Oct 2007, Richard Bejtlich wrote:

> I think at least declaring that we accept and publish full packet 
> captures, allowing for rejection of sensitive data, is an improvement 
> over the overly sanitized option or the incorrectly sanitized option.

 	Perhaps, in addition, a "remove this pcap" form, allowing 
folks/groups some method to request removal.  Granted, this has obvious 
potential for abuse as well.

-- 
Richard H. Fifarek
rfi...@fi...

Re: [Openpacket-devel] New Beta Site Live

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

On Oct 16, 2007 1:08 PM, David J. Bianco <da...@vo...> wrote:
> Aaron Turner wrote:
>
> > A properly worded terms of service/notice when uploading files should
> > help here, but let's be honest here... Sooner or later the lawyers
> > will come.  If you haven't yet talked to a lawyer about CYA yet, you
> > should.  That being said, it's not your fault someone is stupid and
> > uploads a pcap with their username/password in clear text and half the
> > internet reads all their email.  It should be the responsibility of
> > the uploader to make sure the information they are providing isn't
> > damaging.
> >
>
> To me, the big worry is that an OpenPacket user will upload a pcap
> with someone *else's* information in it.  It's hard to come up with a
> TOS that releases you from liability when the injured party is not
> bound by the TOS.
>
> Or maybe it's not.  I'm no lawyer.  But surely some other sites (Wireshark,
> perhaps) must have already dealt with this issue.

I don't know either.  Of course the unless you can verify the uploader
of the pcap has the authority by all the appropriate organizations who
might sue you, all you can really really do is hope the injured party
asks nicely before taking you to court.

Simple situation: I upload a pcap of traffic captured on an internal
RFC1918 network here at work showing some "interesting proprietary
protocol" that has no obvious information that would cause a moderator
to reject it.   However my employer has a strict policy that all
traffic on this network is company confidential.  Company then goes
after OpenPacket for releasing company secrets to the world since they
have no way of knowing/tracking the leak back to me.

IMHO, this isn't so far fetched (a lot of organizations have strict
confidentiality policies) but I don't know how you'd go about
verifying them.

Going back to my other situation: a security company running a test
lab for exploit analysis.  We might be quite happy with sharing pcaps
from this and only this network with the rest of the world, usernames,
passwords & all since they are fake/temporary accounts which exist
only for a limited time in this lab.  Traffic from other labs/internal
corporate networks are considered company secret.

Basically, I think the lower legal risk is more of a function based on
the number of pcap's available on the site then how well moderated the
pcaps are since the moderation standard that should be applied to any
given pcap is an unknown.

Anyways, I think this covers my points sufficiently that I'll stop
flooding everyone's inboxes. :)

-- 
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] New Beta Site Live

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

On 10/16/07, David J. Bianco <da...@vo...> wrote:
>
> To me, the big worry is that an OpenPacket user will upload a pcap
> with someone *else's* information in it.  It's hard to come up with a
> TOS that releases you from liability when the injured party is not
> bound by the TOS.
>
> Or maybe it's not.  I'm no lawyer.  But surely some other sites (Wireshark,
> perhaps) must have already dealt with this issue.
>
>         David
>
>

Hi David,

That's a really good point.

Re: other sites -- they appear to have ignored the issue.  Places like

http://www.packet-level.com/traces/index.htm

seem to host all lab-generated content.

Others like

http://wiki.wireshark.org/SampleCaptures

just ignore privacy concerns, or at least they don't say how they
address those concerns.

Richard

Re: [Openpacket-devel] New Beta Site Live

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

On 10/16/07, Aaron Turner <syn...@gm...> wrote:
>
> A properly worded terms of service/notice when uploading files should
> help here, but let's be honest here... Sooner or later the lawyers
> will come.  If you haven't yet talked to a lawyer about CYA yet, you
> should.  That being said, it's not your fault someone is stupid and
> uploads a pcap with their username/password in clear text and half the
> internet reads all their email.  It should be the responsibility of
> the uploader to make sure the information they are providing isn't
> damaging.
>
> Asking you and your team of moderators to make that decision is quite
> onerous and can't possible take into account different security
> requirements of each uploader.  Example: the security requirements of
> a bank or gov't contractor would be quite different from something
> that came from a throwaway test lab at a security company doing
> exploit research.   Basically, you'd have to be quite conservative
> which means rejecting anything with the slightest security risk.
>

Hi Aaron,

You make good points (as expected).  If we can find a lawyer to donate
some time to the project, then I will accept that help.  Otherwise
we'll have to err on the side of being conservative.

My goal with this project is to get *something* started, but not to
solve the world's anonymized traffic repository problem.  That has
been a research topic for many years.  The result usually means
stripping everything about layer 4 and altering the addresses at layer
3.  I think at least declaring that we accept and publish full packet
captures, allowing for rejection of sensitive data, is an improvement
over the overly sanitized option or the incorrectly sanitized option.

Sincerely,

Richard

Re: [Openpacket-devel] New Beta Site Live

[David J. B. <da...@vo...>]

Aaron Turner wrote:

> A properly worded terms of service/notice when uploading files should
> help here, but let's be honest here... Sooner or later the lawyers
> will come.  If you haven't yet talked to a lawyer about CYA yet, you
> should.  That being said, it's not your fault someone is stupid and
> uploads a pcap with their username/password in clear text and half the
> internet reads all their email.  It should be the responsibility of
> the uploader to make sure the information they are providing isn't
> damaging.
> 

To me, the big worry is that an OpenPacket user will upload a pcap
with someone *else's* information in it.  It's hard to come up with a
TOS that releases you from liability when the injured party is not
bound by the TOS.

Or maybe it's not.  I'm no lawyer.  But surely some other sites (Wireshark,
perhaps) must have already dealt with this issue.

	David

Re: [Openpacket-devel] New Beta Site Live

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

On Oct 16, 2007 12:35 PM, Richard Bejtlich <tao...@gm...> wrote:
> On 10/16/07, Aaron Turner <syn...@gm...> wrote:
> >
> > Heh, well I guess that's the difference between you and I... I would
> > create a "wall of sheep" equivalent for pcap's people upload. :)
> >
>
> Hey Aaron,
>
> I think such a wall would prompt calls from lawyers, and we don't have
> the resources to fight such battles!

A properly worded terms of service/notice when uploading files should
help here, but let's be honest here... Sooner or later the lawyers
will come.  If you haven't yet talked to a lawyer about CYA yet, you
should.  That being said, it's not your fault someone is stupid and
uploads a pcap with their username/password in clear text and half the
internet reads all their email.  It should be the responsibility of
the uploader to make sure the information they are providing isn't
damaging.

Asking you and your team of moderators to make that decision is quite
onerous and can't possible take into account different security
requirements of each uploader.  Example: the security requirements of
a bank or gov't contractor would be quite different from something
that came from a throwaway test lab at a security company doing
exploit research.   Basically, you'd have to be quite conservative
which means rejecting anything with the slightest security risk.

> > On a side note, is there a way to get the list to properly set the
> > Reply-To: header?
> >
>
> What did you have in mind?  The current setup is the Sourceforge
> default, if it matters.

I would set it up so that the Reply-To is back to the list.

-- 
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] New Beta Site Live

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

On 10/16/07, Aaron Turner <syn...@gm...> wrote:
>
> Heh, well I guess that's the difference between you and I... I would
> create a "wall of sheep" equivalent for pcap's people upload. :)
>

Hey Aaron,

I think such a wall would prompt calls from lawyers, and we don't have
the resources to fight such battles!

>
> On a side note, is there a way to get the list to properly set the
> Reply-To: header?
>

What did you have in mind?  The current setup is the Sourceforge
default, if it matters.

Thank you,

Richard

Re: [Openpacket-devel] New Beta Site Live

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

On Oct 16, 2007 10:30 AM, Richard Bejtlich <tao...@gm...> wrote:

> In theory anonymization sounds good, but what does that mean?
>
> Aaron, I know you know this, but anonymization would have to occur at
> multiple layers... I'm particularly worried about removing sensitive
> data about layer 4.  I'd rather not provide a false sense of
> anonymization via replacing IPs when other data is left in layers 5,
> 6, or 7.
>
> My standard rule for the OpenPacket.org moderators will be to reject a
> pcap if they believe it contains anything sensitive.  We are not going
> to jeopardize ourselves by exposing someone's sensitive data through a
> volunteer-based, free project.

Heh, well I guess that's the difference between you and I... I would
create a "wall of sheep" equivalent for pcap's people upload. :)

Honestly, most interesting protocols have some kind of identifying
data in the payload (IP, username/passwords, etc) and the tools to
edit pcap's at this level suck.  I suppose people could load them up
in NetDude, and manually fix them, but that doesn't sound like a lot
of fun for anyone.  You also have the potential for breaking the
protocol in subtle and painful ways once you start editing them by
hand so now moderators have to figure out which are valid,
intentionally invalid (fuzzer traffic, etc) and unintentionally
invalid (over zealous people trying to anonamize their data).

On a side note, is there a way to get the list to properly set the
Reply-To: header?

-- 
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] New Beta Site Live

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

On 10/16/07, Aaron Turner <syn...@gm...> wrote:
> On Oct 14, 2007 2:14 AM, James Pleger <jp...@gm...> wrote:
> > I agree that it is up to the poster to anonymize it, but it would be
> > nice for people who submit large volumes of pcaps to not have to go
> > through anonymizing it on their end. When I was uploading a pcap, I
> > was thinking wow... it would be really neat if the website was able to
> > anonymize it for me :)
> >
> > Just kind of a feature, but still would be pretty cool.. A lot of
> > times stuff isn't sensitive, but might be nice to block out IP's...
>
> I'd have to agree with this one.  Anything the website can do to make
> it easier/less effort for people to upload pcaps will only result in
> more people contributing rather then leaching.  Nobody is going to
> upload files for fame or profit, so lacking sufficient incentive means
> you need to remove as many roadblocks as possible.
>
> My .02USD
>

In theory anonymization sounds good, but what does that mean?

Aaron, I know you know this, but anonymization would have to occur at
multiple layers... I'm particularly worried about removing sensitive
data about layer 4.  I'd rather not provide a false sense of
anonymization via replacing IPs when other data is left in layers 5,
6, or 7.

My standard rule for the OpenPacket.org moderators will be to reject a
pcap if they believe it contains anything sensitive.  We are not going
to jeopardize ourselves by exposing someone's sensitive data through a
volunteer-based, free project.

Sincerely,

Richard

Re: [Openpacket-devel] New Beta Site Live

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

On Oct 14, 2007 2:14 AM, James Pleger <jp...@gm...> wrote:
> I agree that it is up to the poster to anonymize it, but it would be
> nice for people who submit large volumes of pcaps to not have to go
> through anonymizing it on their end. When I was uploading a pcap, I
> was thinking wow... it would be really neat if the website was able to
> anonymize it for me :)
>
> Just kind of a feature, but still would be pretty cool.. A lot of
> times stuff isn't sensitive, but might be nice to block out IP's...

I'd have to agree with this one.  Anything the website can do to make
it easier/less effort for people to upload pcaps will only result in
more people contributing rather then leaching.  Nobody is going to
upload files for fame or profit, so lacking sufficient incentive means
you need to remove as many roadblocks as possible.

My .02USD

-- 
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] New Beta Site Live

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

I agree that it is up to the poster to anonymize it, but it would be
nice for people who submit large volumes of pcaps to not have to go
through anonymizing it on their end. When I was uploading a pcap, I
was thinking wow... it would be really neat if the website was able to
anonymize it for me :)

Just kind of a feature, but still would be pretty cool.. A lot of
times stuff isn't sensitive, but might be nice to block out IP's...

It is late, and I am tired... so this will be the last email for me
before I go to bed

--James

On 10/13/07, Richard Bejtlich <tao...@gm...> wrote:
> On 10/13/07, James Pleger <jp...@gm...> wrote:
> > Sorry for the feature requests late in the game, but it would be nice to:
> >
> >  - anonymize the pcaps if a button was selected when uploading the pcap
> >  - create the tshark output automatically
> >
>
> Hi James,
>
> Thanks for all your feedback.  I'll ask Sharri to take a look.
>
> As far as anonymization, it will be the responsibility of the
> submitter to anonymize the traces.  The OpenPacket.org moderators will
> NOT take that responsibility.  If we feel that a trace is not
> sufficiently anonymized, we will reject it (i.e., not publish it).
>
> Creating Tshark output automatically is an idea, but I'm afraid of
> submitting a file to be processed by code (Tshark) running at
> OpenPacket.org.  Given the dissector vulnerabilities in Wireshark, I
> don't think it's worth the risk.
>
> Richard
>


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

Re: [Openpacket-devel] New Beta Site Live

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

Hi,

Will there be size limit for pcap upload?

Maybe we need to identify the file(pcap) automatically before it can be
uploaded though it needs moderator approval.

I think we need to mention what kind of packet format that we support or
prefer. There are so many different formats out there(snoop, etc), and I
suggest pcap as it is de facto standard.

I agree pcap anonymization should be done by the people who submit it.

All for now, great work ;)


-- 
Best Regards,

CS Lee<geekooL[at]gmail.com>

http://geek00l.blogspot.com

Re: [Openpacket-devel] New Beta Site Live

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

On 10/13/07, James Pleger <jp...@gm...> wrote:
> Sorry for the feature requests late in the game, but it would be nice to:
>
>  - anonymize the pcaps if a button was selected when uploading the pcap
>  - create the tshark output automatically
>

Hi James,

Thanks for all your feedback.  I'll ask Sharri to take a look.

As far as anonymization, it will be the responsibility of the
submitter to anonymize the traces.  The OpenPacket.org moderators will
NOT take that responsibility.  If we feel that a trace is not
sufficiently anonymized, we will reject it (i.e., not publish it).

Creating Tshark output automatically is an idea, but I'm afraid of
submitting a file to be processed by code (Tshark) running at
OpenPacket.org.  Given the dissector vulnerabilities in Wireshark, I
don't think it's worth the risk.

Richard

Re: [Openpacket-devel] New Beta Site Live

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

Sorry for the feature requests late in the game, but it would be nice to:

 - anonymize the pcaps if a button was selected when uploading the pcap
 - create the tshark output automatically

Other than that... there might be some security holes, which I am sure
we can find and stop away pretty quickly. And then you guys could
prolly start getting pcaps from people here to populate the db...

Good games :)

On 10/13/07, Richard Bejtlich <tao...@gm...> wrote:
> Thanks to more excellent, all-volunteer work of our developer Sharri
> Parsell, I am happy to notify you that a beta demo of OpenPacket.org
> is now available at
>
> http://beta.openpacket.org:8080/
>
> Thank you also to JJC of www.redsphereglobal.com for providing 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
> ope...@li... mailing list.
>
> This site is considered "beta," and we are getting closer to public
> announcements of the site. 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.
>
> Thank you,
>
> Richard
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> 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] New Beta Site Live

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

Seems like the forum is broken; I can't access any individual threads.

Also, a cursory experiment suggests the search form may be vulnerable to 
SQL injection (inserting an apostrophe produces an error).

Stretch

Richard Bejtlich wrote:
> Thanks to more excellent, all-volunteer work of our developer Sharri
> Parsell, I am happy to notify you that a beta demo of OpenPacket.org
> is now available at
>
> http://beta.openpacket.org:8080/
>
> Thank you also to JJC of www.redsphereglobal.com for providing 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
> ope...@li... mailing list.
>
> This site is considered "beta," and we are getting closer to public
> announcements of the site. 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.
>
> Thank you,
>
> Richard
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Openpacket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openpacket-devel
>
>