First the good news… I’ve upgraded Trac for the Tcpreplay website which now supports built-in spam filtering. This means I’ve opened up the ticketing system to people who haven’t yet registered an account. Hopefully people will find it easier to open tickets for bugs and feature requests.

The bad news is that rewriting the L2/DLT code is even more complicated then I originally thought. Right now I’m spending my time working on the design, trying to make sure it’s flexible and easy to extend over time. Anyways, if you’re reading this, why not go check out that ticket, read the design document (realizing it’s a work in progress) and let me know what you think?

About 15 years ago an audio tape company challenged people to figure out if it was live or if it was Memorex. It seems that in the networking security space we’re at the same place, trying to figure out if live tools like Metasploit can be replaced by replay tools like tcpreplay.

Now, it would seem obvious that the answer, like most things is that “it depends”, but there seems to be people who are convinced that if it’s not live it’s not a real test.

Probably the best argument against replay tools is GIGO (garbage in, garbage out). If you don’t properly vet your test samples (often in libpcap format) then you’re going to have a bad day. Generally speaking, live tools like Metasploit are easier to validate- they either break into the target or they don’t. Replay tools don’t actually attack anything, and thereby require you to trust that the test case is correct or require you to do more strenuous validation.

The second reason which seems to come up against replay tools is that somehow it’s not really like a live test. Nobody has ever actually been able to give me a case where a libpcap capture of an exploit was different from what was actually on the wire or why resending those captured packets created any differences, but people still claim that it is. They’ve argued that replay tools don’t “emulate the state of the client and server” or that “live tools adapt to differences in the server runtime” but both these arguments miss the point. A IDS/IPS doesn’t know the state of the client or server, it only guesses at the state by watching the packets on the wire. Hence, a replay tool doesn’t need to emulate the state of the client/server, just repeat the externally visible process of those state changes. And that’s something that replay tools do very well.

So are there any advantages or situations where replay is better suited? I think so:

1. Comparative tests. If you’re comparing two products (like two IPS’s) then it’s important to use the same test cases. Live tools, due to their dynamic nature tend to auto-magically adapt behind the scenes.
2. Regression tests. The key behind regression tests is that they don’t change.
3. Single solution. While tools like Metasploit provide a good framework for developing a wide range of attacks, they have a limited number of attacks. This means you often need multiple tools with different interfaces to provide the coverage you’re looking for. Replay tools like tcpreplay provide a unified and protocol/attack agnostic approach to any network based attack.
4. Simple environment. Running live tools requires you to have a victim to attack. Often this means running VMware on a 2nd system, installing multiple operating systems and configuring countless applications to attack. Replay tools on the otherhand are virtually self-contained since they emulate both server and client side of the connection.

What do you think?

Well looks like Richard may have actually gotten OpenPacket off the ground. A public pcap repository is something I’ve often thought about doing since starting work on tcpreplay, but I’ve never had the time.

Limited access to quality pcaps has always been a limitation for users of tcpreplay, so this project may be the perfect companion. I’ll be keeping a close eye on how it develops. Hopefully they’ll have something to look at in a few weeks.

Yep, 3.0.beta10 is available here. So far, at least one person has compiled it successfully, so at least this release is already better then beta8. :)

Anyways, as stated in the release notes, this is the final beta release for 3.0. I’m planning on one release candidate which will have a working tcpbridge (which has been broken since moving all the editing code to libtcpedit) and then put out 3.0.0 shortly after that depending on any bugs people find.

Anyways, give it a try and let me know how it well works for you!

Just a quick note to everyone paying attention that 3.0.beta10 is almost ready. Some rather significant changes since beta9:

• Libnet is now completely optional. I’ve created an abstraction layer supporting BSD’s BPF, Linux’s PF_PACKET, libpcap’s pcap_inject() and libnet’s packet injection methods. So while you can still use libnet, in many cases you won’t need it which should hopefully make installation a lot easier for many people.
• tcpprep and tcprewrite no longer need to run as root. tcpreplay still does for obvious reasons.
• A new and improved packet timing method is available in tcpreplay. Those people needing more accurate inter-packet delays should be better served by this method.
• tcprewrite now can skip rewriting broadcast/multicast IP and MAC addresses which is good news when your pcap contains ARP’s or DHCP packets.
• Various smaller bug fixes which some people noticed and some people didn’t.

Well looks like all the critical bugs with the tcpreplay 3.0.beta8 were fixed in beta9 (at least everyone has stopped complaining), and so I’ve started working on beta10 which should hopefully be the final beta release for 3.0. Mostly the goal of beta10 is to remove libnet as a dependancy which should make compiling tcpreplay much easier for many people.

After beta10, I’ve scheduled one release candidate for early October to finish up tcpbridge and hopefully the offical 3.0 release will go out in early November. So based on past experiance and schedule slippages, I’d guess we’ll see 3.0 sometime around Christmas. :)

Either way, just want to remind everyone to keep those bug reports and feature requests coming in.

After nearly a year between releases (has it been that long??), 3.0beta8 is finally out the door. The changes are actually quite massive due to a huge rewriting effort; and with many additional unit tests (via ‘make test’) code quality should be pretty good too.

This is the first release with a working tcprewrite and modular packet editing code (tcpedit). I\’ve also included a number of end-user requested features. The only “issue” really left right now is that tcpbridge is going out the door untested and I doubt it works. I’ll be sure it’s ready for 3.0 though.

Anyways, be sure to give it a download and file any bugs that you find.