Suricata and pf_ring on RHEL 5.5

I wanted to evaluate Suricata in its recommended configuration, using libpcap linked against the pf_ring library.  But there are a lot of READMEs out there, a lot of them referring to older versions of pf_ring, and the pf_ring documentation itself isn’t very clear.

It took me some digging around and experimenting, but this blog post has a comment by Wil Metcalf that made it all much easier for me.

Succinctly: check out pf_ring revision 4079, then build the kernel modules, then the userland/lib stuff.  You may need to add /usr/local/lib to /etc/ld.so.conf.  I had troubles with the latest version of pf_ring on my RHEL 5.5 installation.  YMMV by this point, of course.

You may also find this post to be useful, although it still talks about patching kernel sources.

Tangentially but also useful if you’re relatively new to RHEL and kernel sources, you might find this post also to be helpful – I did, but there’s probably nothing new there for experienced RedHat admins.

Once you have pf_ring going, you’ll want to rebuild libpcap to link against pf_ring.  I used vanilla source for this, and it was no problem with a straight ./configure && make.  And now suricata:

./configure –enable-pfring –with-libpfring-libraries=/usr/local/lib –with-libpfring-includes=/usr/local/include

And that was pretty much it for me.

Firewall bypass attempts from China?

While examining flow records for a compromised host, I observed several connection attempts from various Chinese IPs, all in the same /24. The source port was always 80, the destination port always 33824. I don’t see anything obvious on the googles or sites like the Internet Storm Centre, so now there will (eventually) at least be something Google-able. I’d appreciate hearing from any other ITSec types about what this might be, either specifically or in general. My suspicion is this is probing for some botnet or another, with source port 80 to try to get by stupid firewalls, but I lack full content data to prove or disprove this theory.

A snark on modern computing

From an IRC rant of mine.  I took out a few comments, but this is otherwise unredacted.  Sorry if you don’t like strong language, skip to the next post.  I don’t claim the thoughts to be particularly original, but I don’t believe I’ve expressed them here, myself, before.

< kraigu> I don’t find it interesting that we’re reinventing mainframes; I find it depressing and shittacular that we’re not just reinventing them, we’re reinventing them _poorly_
< subdriven> How would you do it differently?
< kraigu> I’d see what a 390 would cost me nowadays
< kraigu> it’s amazing to me that 30 years after the PC revolution, we’re going to be using dual and quad core workstations with no less than 2 or 4GB of RAM to run apps in the ‘cloud’
< kraigu> or even if you’re ipad-enabled, you’re still using about 500 times the amount of computing power my parents had to basically run applications in exactly the same way they did on a keypunch machine.
< kraigu> that’s it
< kraigu> I’m writing a fucking JCL interpreter app for the iphone
< kraigu> it’ll submit jobs to EC2 for you

Except I don’t want to be bothered to give Apple money to develop for a platform I don’t have, so you, Kind Reader, have my permission to steal my wondrous idea.

What the hell, it can’t be any worse than any other job dispatcher out there.

Doing pcap stuff with Ruby on a Mac

This is probably old news to anybody who’s used to Ruby on Macs, but I’m not.  I like using MacPorts when I can, so that’s where my Ruby runs from.

I went looking for pcap modules and found a bunch, but the most promising seemed to be packetfu.  It came with a caveat: “PacketFu is reported to work on OS X, assuming you can get pcaprub installed correctly.”

So the first step was to get pcaprub going.  You can get it at rubyforge, the trick is it has a README, a single C source file, and a small ruby script. It turns out the secret is to do ‘ruby extconf.rb’, which will create a Makefile for you, and you can then ‘sudo make install’.

The author of packetfu recommends sticking with sources, available here. Check them out like this: ‘svn checkout http://packetfu.googlecode.com/svn/trunk/ packetfu-read-only’ – I like doing this in ~/src, but your tastes may differ.  Use the pcaprub_linux directory, and again, ‘ruby extconf.rb’ followed by a make / make install.  The test script bombs out – by default it wants to use the fw0 device.  Nevertheless, I pressed on and did as suggested: ‘cd .. && sudo ruby setup.rb’ which finished with no failures.

Note that following these steps will pollute your MacPorts ruby install with files about which it knows nothing – I generally like to avoid this, but it seems like scripting languages insist on having their own packaging systems that make it not quite impossible to work with other such systems.

Then I wrote a little test script that should just count packets:

#!/opt/local/bin/ruby

require 'packetfu'
filename = ARGV[0] || exit
count = 0
incap = PacketFu::Read.f2a(:file => filename)

incap.each do |pkt|
 p = PacketFu::Packet.parse(pkt)
 count += 1
end

puts "#{count} packets"

I would not recommend doing as I did and turning it loose on a 711MB pcap trace – top showed the process using 1.9GB of memory before I managed to get a responsive terminal to kill it.  It fared slightly better on a 12MB trace (a subset of the larger ones) and correctly counted 85411 packets, but still hit 265MB:

real    4m0.359s
user    3m16.012s
sys    0m1.891s

I’m a fairly-incompetent Ruby programmer, but the above seems fairly straightforward – I’m not sure I’d want to turn this parser loose on anything of any real size.  While 711MB is a pretty big trace to be parsing, 12 is pretty small.  To be fair, I had other processes running at the time, including a Windows 7 VM that was patching (unbeknownst to me) but it’s a 4GB dual core machine.  I’d been hoping to more easily pull various bits of data out of the larger file, but it looks like I’m stuck with tcpdump and tshark for now.

ETA: I had been going to post again about xtractr, but it’s not a 100% Mac/Ruby solution. It provides an interface so that I could use Mac Ruby installs to talk to an xtractr instance, but so far as I can tell, there’s no 100% Mac solution. So I’m running it on an Ubuntu box, but I won’t bother detailing how I got it going – it was pretty straightforward, although it required some work I’d already done to make gems sane on an 8.04 system.

Quinn on the 09-10 Oilers

I’ll admit it, the team sucking more than they’ve ever sucked before this year has also sucked the life out of me as far as talking about them goes. Lowetide’s already addressed the high points of the year: Penner’s mostly playing well, the numbers like him, and Gilbert’s coming out of his funk a bit. I hope that management don’t believe their own spin control though, that this season was hampered by injuries – if anything, it’s been helped, if they’d won 5-10 more games they’d be even worse off than they are now. Let’s be realistic, would Khabi+Souray+Hemsky have added more than that? Even 10 games seems wildly optimistic. That would be just enough to what, place them 27th or so?

But in the 1 April press conference, Quinn said something I haven’t seen picked up elsewhere:

Q: You had a line of guys that were -3 that had a tough night together, so I guess we’re still in a wait and see mode?

A: Well, I think… if it’s based on the merit of one game, certainly two, or all three of those guys could come out, we could play shorthanded and have a better night, maybe. It’s not always going to be based on just merit here . . . It’ll be partly management’s idea on what our future is.

That line was O’Sullivan, Brule, and Potulny, although the players mentioned specifically in the previous question were O’Sullivan and Moreau. Moreau was evens on the night, 11 minutes of even strength icetime and 2 shots, 2:58 of icetime on a penalty kill that actually looked pretty good against Detroit, 2 hits credited and 1 blocked shot. Still, thecaptain has to be feeling some intense pressure, even if he’s not admitting to it.

Quinn’s statement is interesting, in that it seems to me to be a fairly damning indictment of a) one of the more highly-paid players on the roster, and a pending free agent; b) one of the young guys that seems to sometimes fill a couple of holes on the roster; c) another younger guy who’s received a lot of positive press this year; and d) team management and how they’re allowing him to coach. I could write a lot about that line + Moreau, but a lot of it’s been said already. I’ll sum it up by saying that if Potulny’s your answer to “Who can provide the Oilers with secondary scoring next year?”, then next year’s team will be as bad as this one’s. I like the player, but he shouldn’t be playing 10-15 minutes a night, much less feature on the power play.

Quinn went on to say that he felt Linglet’s signing was a positive story for the team, that a guy who grinds it out in the AHL can get a chance. Yes, this is a feel-good story in a year that’s been nearly entirely lacking in them, but so was Scott Ferguson on the blueline. Ferguson at least could be counted on to chip the puck out, more than you can say for anybody on the blue now, but 27 year olds who have never before played in the NHL taking somebody’s roster spot doesn’t say much about the roster you have available. This isn’t management giving a young guy a shot; this is management telling the O’Sullivans and Moreaus of the team that they’re just plain not good enough.

For Quinn, if team management really is telling – or even hinting at – him about who to play and who to sit, you have to wonder why it is they brought him and Tom Renney in, and you also have to wonder what that means for the next few years. Maybe I’m reading too much into a single quote, but I think this is a tell.  Next year should be interesting in the “Chinese Curse” sense of the word.  We Oilers fans don’t need reality television, we get it delivered to us two to four times a week, courtesy NHL Centre Ice.