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!
3:06 PM
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
7:24 PM
Richard Bejtlich said…
dre,

Sorry, but that will not get posted. We are not going to expose a product's intellectual property like that.
9:15 PM
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).
3:58 AM
Richard Bejtlich said…
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?
4:02 PM
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.
9:02 AM
Anonymous said…
Congratulations and Thanks!
10:05 PM
Matt Neely said…
Awesome project. I look forward to digging into the traces that have been posted.

Cheers,
Matt
10:17 PM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technical or pol
Read more