Hinky’s Proxy Obsession

I built 64bit snort (x86-64) on my old friend, Debian 4 (“etch”) and had lots of fun doing it.

It wasn’t quite as hard as I thought it would be, but there were a number of stumbling blocks, so I thought I’d post them here if anyone runs across the same issues.

First, our old pal Libnet1.02a is so fucking ancient it predates the AMD64 processor.  The Makefile simply barfs with an “unknown platform” error.  This was easy enough to fix.  First, locate line #172, which should be a comment starting with  ”Recognize the basic CPU types” (duh).  Right under that line should be a line starting with “vax-*”.  Edit that line to include “| x86_64-* |”.  No quotes, as usual.  Run configure, make, make install and that issue is over and done with.

Libdnet was the next big issue, and it was a problem on my 32bit Deb4 system as well.  Normally I hack shit together in /usr/local/src and libs fall into /usr/local/lib.  Unfortunately, libdnet doesn’t like living there and you can run ldconfig all day long and snort will still bitch about not being able to find it.

So start with “./configure –prefix=/usr” and that problem goes away.

I had to build a few things from scratch because Georgia Tech (gtlib.gatech.edu), my favorite apt repository (they seem to be the fastest around),  apparently stopped mirroring 64bit Deb4 and I was too lazy to look for a working repository.  You shouldn’t have this problem.  I had to build libpcap, flex, and bison from source but there were zero issues with any of those.

It took a while to come up with a decent config for snort but what I finally used was this:

Some of that may be unnecessary.  The dynamic examples are buggy and you’ll end up deleting them anyway (you’ll figure it out – trust me).

Once building snort64 was out of the way, I downloaded the rule set and tried out the different pre-compiled “so” (Shared Object) rules.

None of them worked.

That is of course my problem for using an ancient (2006) version of 64bit Debian.  There are a limited number of pre-compiled preprocessors for x86_64 and none are compatible with Deb4 (they all want ‘GLIBC_2.4′, which Debian 4.0 doesn’t have).

This is not going to be a problem for you folks on the cutting edge of Linux.  If I was running Lenny (I hate Lenny with a passion) I’m sure I could have used one of the 64bit pre-compiled preprocessors for Ubuntu.

But I’m not, so I had to roll my own.  And that’s when it got ugly.

Due to “contractual obligations” (NDAs no doubt), snort/SourceFire is only allowed to distribute certain rules in binary format.  They include the source for the non-NDA rules, but how to actually compile them is a trip into Undocumented Territory (“here be monsters”).

Sure, there’s a README file but all it does is explain their legal obligations and reassure you that one of the the pre-compiled preprocessors should work.  That’s it.  That’s all it says.

Thanks, Marty.

But there is a Makefile, so you’re halfway there.  I had to do the following to build the so preprocessors.

First, copy all the files in the src folder (that came with your VRT rules) into the folder where your snort source lives.  I called the folder “so_rules”.  Then fix the locations in the Makefile, like so (assuming you installed the snort source in /usr/src):

Note the variable $SNORT assumes snort is already built and living in your source folder.

Then, comment out the line that begins with “PATH” because I absolutely guarantee you don’t have an Intel compiler.

Now, find the line that start with “libs :=” and remove the following:

These must be the NDA-disqualified shared objects because there is no source to build them from.

Next, just for fun, find and comment out this line:

Why?  Check out the “deleted.rules” file that came with your VRT rules.  There is a lot of old crap you may never see again, but you never know.

Save the Makefile and type “make” inside the so_rules folder (not the toplevel make).  If all goes well, move the *.so files you just built to a folder under /etc/snort (I used “so_64″) and edit your snort.conf file to point to them (the very last line in the “Step 4″ part of snort.conf).

Finally, test your new config out and see what happens. You should see “166 preprocessor rules” intead of “0 preprocessor rules” now and 13 new “Rules Object” entires (I’m using the May 2010 VRT set, so YMMV).

Again, you shouldn’t have to go through this crap if you have a relatively modern 64bit distro of Linux (newer than 2006 I’d say) since the distributed shared objects should run just fine.

What do Windows users do about the lack of shared object rules?  Suffer, I guess, since there are no pre-compiled binaries, 32 or 64bit.

Hopefully, SourceFire will fix that soon.

Are you listening, Marty?