OpenPacket.org 1.0 Is Live

Nearly three years after the initial post describing the idea , I am happy to report that OpenPacket.org 1.0 is ready for public use, free of charge.

The mission of OpenPacket.org is to provide quality network traffic traces to researchers, analysts, and other members of the digital security community. One of the most difficult problems facing researchers, analysts, and others is understanding traffic carried by networks. At present there is no central repository of traces from which a student of network traffic could draw samples. OpenPacket.org will provide one possible solution to this problem.

Analysts looking for network traffic of a particular type can visit OpenPacket.org, query the OpenPacket.org capture repo for matching traces, and download those packets in their original format (e.g., Libpcap, etc.). The analyst will be able to process and analyze that traffic using tools of their choice, like Tcpdump, Snort, Ethereal, and so on.

Analysts who collect their own traffic will be able to submit it to the OpenPacket.org database after they register.

Anonymous users can download any trace that's published. Only registered users can upload. This system provides a level of accountability for trace uploads.

Our moderators will review the trace to ensure it does not contain any sensitive information that should not be posted publicly. Besides appearing on the site, once a trace has been published you can receive notice of it via this published trace RSS feed.

If you have any doubt regarding the publication of a trace, do not try to submit it. When moderators are unsure of the nature of a trace, we will reject it. OpenPacket.org is not a vehicle for publishing enterprise data as contained in network traffic.

I would like to thank all the people who submitted suggestions and did feature testing via the openpacket-devel mailing list. If you have issues regarding usage of the site, consider subscribing to the openpacket-users mailing list or post to the OpenPacket.org Forums.

As time permits I will probably post more on how to use OpenPacket.org strictly on the OpenPacket Blog. I will minimize cross-posting to TaoSecurity Blog and OpenPacket Blog.

I save my final thanks for Sharri Parsell, our Web developer, and JJ Cummings for hosting OpenPacket.org. Without your work we would not have a site!

Comments

Anonymous said…
Richard,

This is great news! Thanks team!
dre said…
Will someone please run a capture of the output from a BPS-1000 full-run and post it? I'm trolling for exploits and need to plug this into tomahawk.sf.net
dre,

Sorry, but that will not get posted. We are not going to expose a product's intellectual property like that.
dre said…
Richard,

It's often difficult to detect my subtle sense of humor.

However, based on your logic -- does this also mean that commercial products' network stack communications will also be prevented from being posted? I'd hate to see a proprietary product or patented specification have its protocol dissected and reversed.

I'm also curious as to how you are going to deal with novel attack paths, new software weaknesses, and/or unknown vulnerabilities (including the zero-day).
dre,

If someone finds a problem with a target using their own methods or an open method, I have no problem posting it. I'm glad you were kidding about the Breakpoint box. I'm pretty sure posting that would be a violation of the TOS for whomever posted it, and I don't want to butt heads with vendors. I expect a person who posts evidence of a 0 day to practice responsible disclosure, but perhaps we should make a policy clear. That's a good point you have mentioned. Do you have a recommendation?
dre said…
protect and monitor your web application. detect all kinds of attacks against it, including registration and reputation-based attacks in addition to mitre capec.

have a clearly defined policy and lock-down accounts that violate the policy. punish all valid users as well as the individual who posted the unwanted item by disallowing any new posts for a exponential time period.

classify packets by categories with tagging. use analytics. disallow access (even for viewing) for certain categories from time to time, if/when that category becomes a problem. enable posters (which require logins) to create, police, and group-modify tag information.

integration of a web-of-trust would be nice, but SSLifying actual full packet data with no-store/no-cache is about as good. putting the full packet dumps in an rss feed would be really bad.
Anonymous said…
Congratulations and Thanks!
Matt Neely said…
Awesome project. I look forward to digging into the traces that have been posted.

Cheers,
Matt

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics