iPhone, meet Wireshark...
If you wanted to see what the apps on your mobile device are up to (especially operators trying to understand the impact of mobile apps on their infrastructure), current instructions on the web involve jail-breaking, setting up access-points and hubs and what not. It's gotta be lot simpler than that. Blog: http://bit.ly/cBFvDd Code: http://github.com/pcapr/l2bridge A couple of things you can do with the packets you capture: . Use http://www.pcapr.net/xtractr to analyze the apps, generate reports and charts and go to town . Be nice and share non-sensitive application traffic back to the pcapr community May the packets be with you! Thanks, The Pcapr Team http://www.pcapr.net/ http://twitter.com/pcapr http://labs.mudynamics.com
Visualizing Application Flows with xtractr
One of the challenges of troubleshooting networks with packet captures is that you quickly lose the bigger picture with the volume of data. And static reports just don't do justice to the flurry of activity on networks. We just posted a video on visualizing application flows using xtractr. You can learn more about xtractr here: http://www.pcapr.net/xtractr http://labs.mudynamics.com/2010/09/30/visualizing-application-flows-with-xtractr K. --- http://www.pcapr.net http://twitter.com/pcapr http://labs.mudynamics.com
Re: PCAP Sanitization Tool
Log sanitation is a whole lot easier than packets. AFAIK, santizing pcaps is an intractable problem because of various kinds of encodings that exist within packets. Examples: - FTP IPv4 addresses are comma separated - DNS does label encoding of domain names (especially with pointers) - Forwarded emails contain deeply-buried domain names and IP addresses within gziped, based-64 encoded mime attachments. So, I don't think you are going to get what you are asking for. That said, there are tools that can strip out the payload and reassign IP addresses and port numbers. K. --- http://www.pcapr.net http://twitter.com/pcapr http://labs.mudynamics.com On Wed, Jun 16, 2010 at 10:18 AM, Michael Collins mcoll...@aleae.com wrote: FLAIM: flaim.ncsa.illinois.edu On Jun 16, 2010, at 12:58 PM, Bein, Matthew wrote: Hello, Anyone know of a good tool for sanitizing PCAP files? I would like to keep as much of the payload as possible but remove src and dst ip information. Mike Collins mcoll...@aleae.com
Announcing: Ruby API for xtractr
What started off as a way to unit test the RESTful API for xtractr has now turned into a Ruby gem that we are releasing as open source. First xtractr, then nuggets and now a gem. We are happy to announce a Ruby gem for xtractr which takes all the goodness of Ruby and interacts RESTfully with xtractr for oh-so-fun network forensics and troubleshooting all from within IRB, the interactive Ruby shell. Blog: http://bit.ly/baW3zZ Code: http://code.google.com/p/pcapr/ Thanks, K. --- http://www.pcapr.net/ http://www.mudynamics.com http://labs.mudynamics.com http://twitter.com/pcapr
Re: anti-ddos test solutions ?
http://labs.mudynamics.com/2009/04/10/ddos-testing-network-applications/ http://www.pcapr.net/dos YMMV, but mudos converts *any* IP packet into a DoS generator (it's free). K. --- http://www.pcapr.net http://labs.mudynamics.com http://twitter.com/pcapr On Wed, Mar 17, 2010 at 11:28 AM, Stefan Fouant sfou...@shortestpathfirst.net wrote: -Original Message- From: Charles N Wyble [mailto:char...@knownelement.com] Sent: Wednesday, March 17, 2010 12:16 PM To: nanog@nanog.org Subject: Re: anti-ddos test solutions ? bit gossip wrote: Nessus is a vulnerability scanner: http://www.nessus.org/nessus/ Ixia provides a full Nessus implementation in one of its platform. Well these days I would use http://www.openvas.org and http://www.metasploit.org for vulnerability scanning and analysis. However that wouldn't be a DDoS, but could certainly lead to DOS. If you can get your hands on a PCAP from a previous attack, you could also use something like Bit-Twist which will allow you to manipulate things like the destination IP and also the transmission rate, etc. Pretty useful tool to include in the DDoS simulation toolbox. http://bittwist.sourceforge.net/ Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
Announcing xtractr (on pcapr)
We just released xtractr, a collaborative cloud app for indexing, searching, extracting and reporting on large pcaps. This thread on NANOG is one of the many use cases that xtractr attempts to solve: http://mailman.nanog.org/pipermail/nanog/2009-December/015661.html You can learn more about xtractr on our blog: http://bit.ly/d7yrKl or watch a demo: http://www.pcapr.net/xtractr Thanks, K. --- http://www.pcapr.net/ http://www.mudynamics.com http://twitter.com/pcapr
Re: D/DoS mitigation hardware/software needed.
If you want to recreate D/DoS from captures (for testing purposes) you might want to check out: http://www.pcapr.net/dos This lets you validate how your mitigation solutions are holding up. K. On Mon, Jan 4, 2010 at 1:19 PM, Rick Ernst na...@shreddedmail.com wrote: Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned several times but they haven't been responsive to literature requests (hint, if anybody from Arbor is looking...). Our current upstream is 3x GigE from 3 different providers, each landing on their own BGP endpoint feeding a route-reflector core. I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device Netflow can lag a bit in detection. I'd be concerned that inline devices add an additional point of failure. I'm worried about both failing-open (e.g. network outage) and false-positives. My current system is a home-grown NetFlow parser that spits out syslog to our NOC to investigate potential attacks and manually enter them into our RTBH. Any suggestions other than Arbor? Any other mechanisms being used? My idea is to quash the immediate problem and work additional mitigation with upstreams if needed. I could probably add some automation to my NetFlow/RTBH setup, but I still need to worry about false-positives. I'd rather somebody else do the hard work of finding the various edge-cases. Thanks, Rick
