Ok, last post was a rant was about how Ruby sucks. This post is about how damned cool it is. Long story short, I needed to switch some code from a fork() model to multithreaded or select(). I really wasn’t excited about working with threads or Ruby’s rather coarse select() API. Then I found GServer. Continue reading
Ok, I’ll the be first to admit that I’m no OO guru. Most of my OO coding has been done in Perl for heaven’s sake. I’ve also dabbled a little in C++. Now I’m learning Ruby. Ruby has some really cool idioms and features which really make writing code easier and cleaner. Of course, not everything in Ruby has me singing it’s praises. This is another of those rants…
Basically, I’m trying to write a brain dead simple class wrapper around multiple temporary files. One feature of the class was to be that the user doesn’t have to manually delete the temp files…. basically when the class goes out of scope, I’d hook into the destructor to delete the files automagically. I know this sorta thing is doable in Perl, Java and C++. Imagine my surprise when I found out that Ruby has no destructor, just a “finalize” method which is only called during garbage collection- NOT when the object goes out of scope. As a matter of fact, Ruby doesn’t provide any way to do what I want without using closures which severely limits my class since it’s designed to be managed remotely sorta like RPC.
For a language which seems to pride itself on it’s flexibility and ability to override just about any method, not being able to hook into when the object goes out of scope is just plain lame.
I was just browsing SourceForge and noticed that they seem to have (finally) fixed the project stats. Anyways, I decided to check out the tcpreplay stats for the last two months. Did the math and people are downloading tcpreplay 40.9 times on average per day. Wow. Honestly, I didn’t think there were close to that many people downloading the source code… after all most people can get tcpreplay from BSD ports, RPM or the like.
Anyways, short status update. I had hoped to work on tcpreplay over the holidays last month, but was too burnt out to do any coding. Hopefully I’ll be able to find some time soon to continue the work on the DLT plugins. On a side note, I found someone else is working on a similar suite: Bit-Twist. Looks like he’s made some good progress in under a year.
Just got an email from Freshmeat saying that they’ve de-listed the libnet library from their database. Sure enough, www.packetfactory.net is offline. Anyways, I’ve emailed Mike to see what’s going on. Until then I’ve uploaded my last copy of the source code to here: libnet-1.1.3-RC-01.tar.gz
UPDATE: The email to Mike bounced and the libnet mailing list has been basically dead for over a year. Starting to smell like abandon-ware. Also, I could of sworn libnet-ng had an actual web page, but looks like that was taken offline or I was horribly confused.
So one of the tcpreplay users has pointed out that it sometimes it doesn’t send the entire packet. I thought this was very odd since tcpreplay is actually quite simple relatively speaking so there’s not much room for bugs like this to sneak in. After some research I figured out the problem was a broken pcap capture file.
Specifically:
The libpcap specification stores multiple instances of the packet length:
The issue becomes when the snaplen is less then the caplen. This shouldn’t happen, but it may due to bugs in code. The result is that the libpcap library lies and returns the lesser of the two numbers (snaplen) and truncates the packet- even though libpcap advances the file descriptor caplen bytes. This clearly violates Postel’s Law.
Of course the maximum stored packet size is rather redundant- no reason you couldn’t pick a reasonable default buffer size (say 65535 bytes) and realloc the buffer if the stored packet size is larger then that. But libpcap doesn’t do that, and doesn’t provide an API to let you know that this is happening. The result is that tcpreplay only has access to incorrect information and fails to send the entire packet.
I’m currently working on the libtcpedit DLT plugin support. The major goals are:
1. Make it easy to add support for new DLT types in the future.
2. Support the top 3 or 4 most commonly used DLT types out of the box for 3.0.
With that in mind, I’m requesting people let me know what DLT types other then Ethernet they work with the most. Some DLT’s to think about are: Linux SLL (cooked socket), BSD Raw IP, NULL, FDDI, PPP, Cisco HDLC, Prisim, Aironet, IEEE802.11 and IEEE802.11 w/ radio header.
So far I’ve got votes for:
– Cisco HDLC
– Linux SLL
– “the most common WiFi DLT types under Linux” (anyone know which that might be?)
When you vote, please vote for a #1 priority, #2 priority, etc. Just rattling off a bunch of DLT’s isn’t all that useful to me.
For a full list of libpcap DLT types check here.
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:
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.
So here’s the deal: I don’t charge a single cent for tcpreplay regardless if you’re using it for educational or commercial use. You can even embed tcpreplay in your product and sell it, I don’t care.
I don’t charge for the docs, man pages, or FAQ even though I spend quite a bit of time trying to keep the docs up to date, accurate and useful. I’m also more then happy to provide free technical support to anyone who emails the tcpreplay-users mailing list. Having people use the list means that the questions and answers are archived for future use and it gives other people a chance to help you out. If you only email me, then only I can help you and nobody else can benifit from the answer.
I suppose there are two ways you can look at this, “something for nothing” or “you get what you pay for”; either way, it seems like a pretty good deal to me. On the other side of the coin, in the last 5 years I’ve been working on tcpreplay, I’ve gotten little fame, a few “thank you” and a DVD. Obviously, I’m not doing this for the money.
So here’s the rub, don’t get offended when I balk at giving you free, 1-on-1 support directly over email. Contrary to popular belief in the open source community, developers are not your slaves. We don’t have to give you support. We help out users because we like to and because it helps make our project better. While I’m sure some developers are more then happy to go to great lengths to help you with your problems (even when they are clearly between the chair and keyboard), you’ll have to excuse me if I’m too busy to do so. And you’ll have to excuse me if I do a poor job of explaining it for the hundredth time to someone who was too lazy to read the support page without sounding like an a**hole.
So please, please use the tcpreplay-users mailing list.
