Mac OS X User Installs Snort From Source

In this particular post, the idea is to give the reader, who may be used to installing a disk image (dmg) on Mac OS X, or using Install Shield to install something on Windows, a little insight into how to move up to the next level, and install software using the original source code.  We will be loosely following the instructions contained in Andrew Lockhart’s “Network Security Hacks” book.  According to Lockhart, Snort is considered the “undisputed champion of open sources NIDs”.

High-level Overview:

Here’s a high-level summary if you want to get the quick overview of what we are going to do:

[EDIT: add links for each section]

1.  Install and configure your compiler (gcc).

2.  Download snort

3.  Download pcre

4.  Configure your path so gcc is able to compile

5.  Set up the root user

6.  Run the configure and makefile scripts to install pcre

7.  Run the configure and makefile scripts to install snort

8.  Install the rules

9.  Fire up Snort for a quick spin!

Without further ado, here is our use case:

Use Case Name: Mac OS X User Installs Snort From Source.

Actor:

First we describe the actor:

Mac OS X Beginner User:

This might be of varying interest to folks with skills ranging anywhere someone familiar with Unix, but not Mac OSX, to a Windows user with some Windows programming skills such as Visual C++ or .NET.  Perhaps you’ve compiled CVS from scratch on a Solaris server, and you’d like to do the same for Snort on Mac OS X?  Or even someone simply interested in how one compiles and installs a nicely packaged Unix application.

Objective:

The main objective is to install Snort by compiling the source code.  Installing a binary is easier, but sometimes finding a recent binary is not easy, and furthermore, it may not have the best performance.  Here is a quote from the Snort Cookbook:

IDS systems are critical on efficiency. The precompiled packages are easy and quick, but they fail to optimize the system to your exact hardware. If you start to hit performance related issues with your binary install, try recompiling from source, which may solve the problem.

However, along the way, as an additional benefit, you will learn much that will be useful when installing any software from source on Mac OS X.  

Trigger:

[EDIT: More info on IDS and benefits]

You have a requirement to run an Intrusion Detection System on your network, and have chosen Snort.  However, there’s no binary available for your particular OS, or you wish to compile from source to ensure good performance.

Precondition (Requirements):

You’ll need some way to uncompress files.  This is Unix, so we already have standard tools for this - tar and gzip.  Simple instructions for using these are specified in the section on installing the rules at the end of this document.  On the other hand, there are nice GUI tools available, which make things a little simpler if you are new to Unix, and save you such questions how do I use tar, or gzip?  What are the arguments?  As this guide is intended to be a gentle introduction into both Snort and finding your way around a Unix system, we have strived to minimize the amount of different things you need to learn - that can come later.  Therefore, I like StuffIt, and OS X has a built in archive tool also, however it is not as powerful and flexible as StuffIt.

Ok then, let’s get started….

Use case flow:

1.  Install Xcode.  If you are doing any sort of programming on the Mac, you might already have this installed, and it includes gcc, so is the copy of gcc I used.  You can certainly download gcc on it’s own, of course, since the two copies should reside peacefully together, but I’ve taken the approach that, where possible, we try the simplest path first.  XCode takes care of installing gcc for us, although, as we’ll see, there are a few changes that need to be made.  If later you realize you need a specific version of gcc than that which comes with Xcode, then you will of course need to download gcc separately.

2.  Download Snort (I am using 2.8.6.1),  expand it with some utility like StuffIt, and copy the directory from your downloads directory to a directory such as your Development directory.  Who knows, now that you have the source, perhaps you can contribute a patch to the snort team?

3.  Now we need to do some work from the command line, so we’ll need to open a shell.  If you are a complete Mac newbie, here is how to do that:

From the finder, open up, got to your Applications->Utilities directory, and find terminal.app, and drag that to your “dock”.  Clicking on that will open up a window which allows you to key in commands, much like you would at a DOS prompt.  This is a Unix Shell, which is, according to the Bash Reference Manual, “a macro processor that executes commands”.

4.  In your shell, cd to the snort directory and run ./configure && make.  According to my O’Reilly book, that should be it.  In a few seconds, I will be off and happily running Snort?  The best laid plans.

Instead, the script fails with an error, and prints text similar to the lines below:

checking for gcc… no

checking for cc… no

checking for cl.exe… no

Executing your configure script (part 1: Configuring your compiler)

Let’s see, checking for gcc… no.  That means it didn’t find the GNU C compiler.  With the next line, it checks for a standard C compiler, I believe this is Sun’s version.  Then it seems to think we might be on Windows and looks for  cl.exe, which is the Microsoft C++ compiler.  Ok, this script isn’t too smart, we are not on a Windows machine.

A compiler - that would help.  That should be easy enough.  Surely Mac OS X has a C compiler?  I know it’s somewhere, let’s see..

We will simplify the install and put aside the question of *which* C compiler would be best to use.  GNU gcc is probably a good choice for most open source software because it is probably the de facto standard compiler out there.  One advantage is that it runs on nearly every version of Unix, and is well known and documented.  There are many other good compilers - IBM’s XL C is a good choice for AIX, Sun’s cc Sun Solaris, Intels (do they have one for the mac?).  But gcc is the standard, and many, many apps use this, so we’ll go with that for now.  Why make things unnecessarily harder?  Now, if you realize later that it simply won’t compile with your favorite compiler, we might have to come back to this question.  But for now, we are focusing on gcc.

Turns out, from a little web surfing,  that gcc should be installed with XCode

XCode installation guide is a little dated, but tells you where gcc should be if you installed it with xcode (I downloaded xcode, it was not from a cd):

http://developer.apple.com/mac/library/documentation/Xcode/Conceptual/XcodeCoexistence/Contents/Resources/en.lproj/Basics/Basics.html

So, now we know gcc is in the directory below:

 /Developer/usr/bin/gcc

1.  Ok, now we add it to our path:

crank up a text editor and create a file called .profile in your home directory (/Users/<username>)

Add the following lines:

GCC_PATH=/Developer/usr/bin

PATH=$PATH:$GCC_PATH

export $PATH

or you can of course do this from the shell, by firing up your favorite editor like vi:

cd ~ (to home dir)

vi .profile

and now you can add the lines.  If you’re not ready to dive in to the intricacies of vi, then simply use your favorite text editor.

2.  To reload the updated .profile, type in the following command (you can also exit out from the terminal app and then reopen it):

source .profile

3.  Let’s echo the path, to make sure it’s configured right:

echo $PATH

You should see the gcc directory now in your path.  Good.  Now we have gcc there, and make sure we didn’t spell a directory wrong:

gcc —version

excellent — we have now have a C compiler.  Well, we always had one, now it’s configured to run from the command line.

Executing the configure script (part 2):

First, what does the configure script do?  The top of the configure script for Snort states the following:

“Guess values for system-dependent variables and create Makefiles.”

Well, literally, it runs whatever is in the configure script.  The idea for the configure script is to verify that all the supporting machinery and configuration is available to compile the source, and create a makefile with all the applicable compiler flags and other settings appropriate for the particular “target” environment, in this case, Mac OS X.   The configure script will take care of setting all the compiler flags to provide for the best performance possible, and this is why your custom-compiled binary will perform better than a generic binary that you’ve downloaded.  This is to accommodate thousands (well, almost) different varieties of Unix.  For example, for shared objects, what is the suffix?  Usually it is .so, but — not always.  Another good example is that you can compile the application for particular chips, for example[EDIT: could use a few lines here to better describe the purpose of the configure script.]

Probably the best way to understand the configure script is to browse through one.  Therefore, browse through the file quickly to get the gist, here’s an example:

   msvisualcpp | msvcmsys)

      # This compiler won’t grok `-c -o’, but also, the minuso test has

      # not run yet.  These depmodes are late enough in the game, and

      # so weak that their functioning should not be impacted.

      am__obj=conftest.${OBJEXT-o}

      am__minus_obj=

Marvel that there are actual useful comments in the script!  One of the nice things about working with open source code is to get the chance to work with nicely written code that is well-documented.

1.  From the snort directory, execute the following command:

./configure

Actually, if you want to save yourself a little work, send the argument —enable-zlib to the configure script:

./configure —enable-zlib

As we’ll see later on when editing the configuration file, this is required.  You can type ./configure —help to see the various configuration changes available.  For example, if you will be logging to a database, you might want to add the —with-oracle=DIR argument.

Well, it still breaks, this time with the error “c compiler can’t make executables see config.log”

So we google first, and for this bland, generic, cryptic error we get suggestions like “install XCode again”.  Fair enough, given the limited detail.  Seriously, this is probably a good option.  On the other hand, you have a really new version of XCode, so you don’t have that much faith in this.  Besides, it’s kind of the “reboot your computer and try again” answer, unless the version of XCode really is different, or you do the install differently, you’re not really doing anything differently.  And what is that saying?  Doing the same thing twice and expecting a different outcome is, uh, not too brilliant.  Something along those lines.

Right, instead, let’s do this.  Let’s see what the error is by reviewing config.log:

Looks like there is some confusion over what is an arg, but the big problem is gcc is failing to compile a simple one line C program.

Ok, let’s try their simple test, and see if gcc really works at the simplest level, can we compile a 1 line program?

touch configtest.c, start up vi and add the line (or, again, using TextEdit or the like)

gcc configtest.c

—> here’s the error:

ld: library not found for -lcrt1.10.5.o

the “.o” suffix tells us this is an object file.  [Add more detail here.]

It’s failing in the linker (ld), which is not finding a library.  There is a dependency here, for some reason this file isn’t there.  Go back to Google, maybe this additional detail will be more easily fixable than installing XCode again (although in many cases, this is probably the simplest solution, crazy as it seems - so we’ll keep this idea as a strong plan b):

Ok, here’s an interesting post on mac site, gives us the hint that the “-l” is an argument and the lib is actually crtl1.10.5.o.  I’m using the same platform (Mac OS X Snow Leopard, XCode 3.2.1).

http://code.google.com/p/remail-iphone/issues/detail?id=3

Hold on a moment.  At this point, you might be a little mystified at this point: So I’m downloading an App (XCode), with some tools, and the darned thing doesn’t even compile a one line program?  If your standard configure script has this nice, simple test, why couldn’t the XCode installer have done something similar, and updated the path correctly?  [Note: This is could be because the version of Xcode I used was somewhere between OS X 10.5 and 10.6.  I have since updated the paths to point to the 10.6 libraries, and it still works (simply changing from the MacOSX10.5 sdk to the MacOSX10.6 sdk).  I have not tried compiling without these paths.]

They show two workarounds, one involving setting up a link to point any references to 1.10.6 to 1.10.5.  First we need to find the library, and then we’ll create a symbolic link.  [Edit: add post on symbolic links].  Wait a minute - maybe this is a path problem, and the library really is somewhere?  Let’s see:

cd /Developer

# the following command is an immensely useful Unix command.  In this case, it tells use to find all the files matching the name “crt1.10.5.o”, starting from the current directory, indicated by the “.” symbol.

find . -name crt1.10.5.o -print

Here we are:

/SDKs/MacOSX10.5.sdk/usr/lib/crt1.10.5.o

It’s in the 10.5 directory, but we are using 10.6, and with ls, we see there is no MacOSX10.6.sdk

Let’s see where that is.

Wait a sec.

So maybe this directory is not in the path configured by XCode?  Like Gabor, I’m not an expert on gcc, so I’m not sure how we tell it where the right libraries are.  Let’s see, in Visual C++, this would be through the options->Settings (or something like that), or in the VCVARS bat file for the command line, but that is the Windows world.  We’ll have to figure out the equivalent for gcc.

Instead of our default response to any error being more googling, let’s try a smarter search this time by bring up the manual page for gcc.  In Unix, we can instantly find a short summary about nearly any Unix utility by typing in “man” followed by the utility your are interested in.  The following command, for example, will bring up the “man” page for gcc:

man gcc

Another useful feature, once we are in the man page, is to hit the forward slash, and then type in some text we want to search for.  In this case, we want to search for “library”.

Hm, now we now what the -l stands for - library.  Maybe we could pass the full path to this library?  Set that idea aside, easy to do, but it’s likely there could be many other missing libraries, so better to set the path to a directory.

Ok, back to Google.  Using man has been useful as now we have some more information on the right search query.  Something like “gcc library path mac os x”.  Sure enough, here’s a link from StackOverflow.com:

http://stackoverflow.com/questions/1365211/error-in-xcode-project-ld-library-not-found-for-lcrt1-10-6-o

Most of the answers don’t apply, since they are configuring the path through XCode, but here we are, Stefan has a way to do this via the command line.  Back to our profile, and we add the environment variables in.

#use MacOSX10.6.sdk if you are using > Xcode 3.2.1, which includes

#the 10.6 directories.

SDK_PATH=/Developer/SDKs/MacOSX10.5.sdk

export C_INCLUDE_PATH=$SDK_PATH/usr/include

export LIBRARY_PATH=$SDK_PATH/usr/lib

It’s good to take a moment and post a comment at stackoverflow, or even simply using your “karma” to indicate that this answer was right (or wrong).  This requires us to login at stackoverflow, no anon permitted - argh.  (Stackoverlow is a bit overzealous sometimes.)  But it is worth it, let’s contribute back, since we’ve learned something, right?

Compiling and Installing pcre (Perl-compatible regular expression library)

That complete, we run configure again, and then we pause to consider the new error message:

checking for pcre.h… no

   ERROR!  Libpcre header not found.

   Get it from http://www.pcre.org

Now, one thing that’s very nice is that you get a great error message from the snort config script - what a welcome change from the typical cryptic error message!  Thank you, snort!  You are now congratulating yourself on having selected snort, as having good error messages (and good comments) in their install script indicates this code is well-thought out, and probably is nicely designed.  And with open source, we can actually verify this by browsing the source code.

Cool, this is the library mentioned in the library book, so we should somewhat expect this.  PCRE stands for Perl-Compatible Regular Expressions and allows a C program to do the same advanced regular expression matching that Perl is known for, and even uses the same syntax and semantics as in Perl.  Being a coder, you gambled somewhat on the possibility that this regular expression library might be included with OS X, and if not, the compile will fail.

Which it does, as we have seen.  Surely there’s a version of pcre *somewhere* on OS X, that is available in my path?  In your best Steve Martin impression),  “but nooooooooooo”.

Alright, no complaining - with Mac OS X you do not need to install another key library, which is called libpcap.  The O’Reilly book actually spends a paragraph going into a little detail on libpcap - which we happen not to need, so be content that running on this Unix flavor has gotten you a little bit at least.  [EDIT: this is a key library.  Add some detail, and a link to Martin’s paper on Snort, which discusses libpcap.]

Besides, we’ve gotten the compiler running, and installing pcre should be very similar to snort itself, you’re a seasoned pro by now - it’ll be a snap, right?

So here we go, same thing, got to the directory mentioned above, and download the bzp file.

[Text like this could be in a sidebar.  It really isn’t relevant to the main purpose of this document, but it is interesting by itself.  Perhaps the subject of another article.]

After browsing a few web pages at the PCRE site, you see they developed this for some mail program, and now, it’s a widely used utility, far beyond their original expectations probably, and certainly much more used than their mail program.  Interesting, reminds me of Ruby on Rails.  No matter how big BaseCamp is, it will never approach the level where Rails is.  Do you use, or even know the names of any of their actual commercial software?  Ok, interesting, but let’s keep focused.

We are close (I think) to getting snort up and running.  Well, let’s say 80% - it’s always that last 10 or 20% isn’t it though?

Next, uncompress with StuffIt, copy it to your ~/Developer directory.

1.  cd to the directory and run ./configure

And voila, it works the first time.  Maybe we are really on our way here!  Nice.

NOTE: The following does not currently work, so stick with 32 bit for now!

For extra credit, since Snow Leopard supports 64 bit code, you can also compile the library and create a 64 bit version instead of 32 bit:

From the Apple instructions for GCC:

You must specify a 64-bit architecture (PPC64 or x86-64) with -arch ppc64 or -arch x86_64. You can also compile binaries with multiple architectures, such as -arch ppc -arch ppc64 -arch x86_64.

According to the PCRE Configure script help, we can set the flags as environment variables:

  CXXFLAGS    C++ compiler flags

Use these variables to override the choices made by `configure’ or to help

it to find libraries and programs with nonstandard names/locations.

Therefore, we can add this environment variable to our .profile

export CPPFLAGS=’-arch x86_64’

One thing though.  I wonder if this is in our build path now?  Is that done by the configure script?  Maybe, but you’re not fluent enough about pcre, or configure scripts in general to know.  Let’s take a look at the pcre readme file.  It happens to be very detailed and well written, and has some good suggestions on how you might want to tweak the build.  Past that section, it tells us what configure did.  Aha, here we go - run make install!  According to the pcre readme file, this will

“install PCRE into live directories on your

system.”

Perfect!  Note to open source developers - this is how to write a readme file!  You should also note that, like Snort, PCRE comes with a wealth of good documentation, demos and test programs.

Ok - we didn’t execute make yet.  Configure just, well, makes sure you have a compiler and things like that, and creates a makefile according to your environment.  But it didn’t actually execute make yet, and build the libraries libpcre and libpcreposix that we need for snort.

So we run make.  And it fails.  Argh.  See, thought you were 80% of the way there, now we have a component that is failing to build, not even our main program!  Sigh.  So close.

Oh well.  So we walk up the output till we see what seems to be the first error.  Hm, can’t find a standard C library, how can that be?

pcrecpp.cc:36:20: error: stdlib.h: No such file or directory

pcrecpp.cc:37:19: error: stdio.h: No such file or directory

pcrecpp.cc:38:19: error: ctype.h: No such file or directory

In file included from pcrecpp.cc:39:

/Developer/usr/bin/../lib/gcc/i686-apple-darwin9/4.0.1/include/limits.h:10:25: error: limits.h: No such file or directory

Ok, here we go, some path problem again, these are very core header files.  Standard lib and Standar I/O.  Even the most basic C program would not compile without these.  But if we had to add the library to our path, maybe we need to add a directory with the header files?  Again, I know how to do this in Windows Visual C++, so let’s see if we can replicated this, following the library example above, in which Stefan showed us how to add the lib file to the path.  Wait a minute, wait a minute!  Didn’t we just add the include path previously, per Stefan?  Did we key it in wrong somehow?

First, we need to find where these header files are.  Back to our find command:

find . -name stdio.h -print

Ok there it is, exactly in the path we have specified in our .profile.  We test the variable name in the following way:

ls -lrt $C_INCLUDE_PATH/stdio.h

and indeed, the file is displayed, so that’s not the problem.  Back to the drawing board!

So what is going on?  It’s almost like everything is running smoothly, and then somehow this path is wiped out - surely this header file is referenced in the makefile previously?

We go back through the readme more closely this time.  Anything about mac os x?  Nope, just some tidbit about hp.  Unix-like systems.  BSD.  Ok, review the configure output, anything blow up that looks important?  Nope, and more interestingly, we see configure is checking for some of the header files later claimed to be not found, very strange.  Here it finds stdlib.h, here it finds limits.h.  Back to readme - what about the very first item here, about using the —disable-cpp?  We certainly don’t need that, aren’t we using gcc?  On a whim, you try that - and it works!  Or was it merely that you ran it again and it worked?  Ran ‘make clean’?  Ok, strange.  [Note: Using the newer version of Xcode (>3.2.1) I did not need to do this, but I am leaving this here in case anyone runs into a similar issue.]

Setting up the root user in Mac OS X

All ready, now we need to install as root.  Uh oh.  what’s our root password?  If I su to root from my regular user account, it fails with a login error.  Wait a minute, I’m sure I configured root, why doesn’t this work?  Time for the Apple manual, we hit google again.  (No wonder Google is making billions).

Here we go, a knowledgeable article on setting up the root password.  Looks fairly convoluted, so I won’t waste time replicating the steps here.  Simply follow Apple’s instructions, and note that once you authenticate, you need to enable the root user from the Directory Utilities *menu* bar (at the top), not in one of the dialog windows.  Or you can reset the password, if you’ve already enabled it, but never wrote it down, like someone did.

Log out of the admin account, log back in as your regular user, since you already have the profile configured for that user.  Huh, same error.  That’s the right password, what’s the problem?  Does my user need admin rights, you say?  Aha, let’s log out of regular user, log in as the admin user - whatever user you have set up in your preferences, considering you have followed best practices by using a special “admin” account.  Now, from the shell window, copy the profile from your regular users home directory, execute source to run it, and then su to root.  Ahah, this time you get in.  Hopefully you will remember that next time ;)

You run make install for pcre, and it works.  Take a moment to look through the output as usual.  Hm, there’s a message about the libraries have been copied to /usr/local/lib - is that a standard directory?  Well, it is on most versions of Unix, but it might not be for the flavor Mac OS X uses, so we keep that item in mind.  Anyway, pcre is installed and ready to go, you are now got your second wind back, it’s the home stretch!  Whew!

Configuring and Installing Snort

Back to Snort.  Now run make.  Huh, no make file?  I thought configure worked, but make was failing?  Let’s read through our notes (wasn’t it a good idea making these notes?), did we ever actually run configure successfully?  Oh.  It gets a little confusing building two libs, and keeping them straight.  We did fail in the configure script for snort, so let’s run that again, now that we should have all the underlying components ready.  Hm - what about the /usr/local/bin?  Being a programmer, we can run the script again and see if it works, at the relatively low cost of typing in the command.  Besides, we are also banking on the idea that the configure script is smart enough to know about the /usr/local/bin dir for pcre, after all, that’s the purpose of the config script right?

And so indeed, it is, and it works!  Glance through the output, and we see there are a bunch of Makefiles created, including src/win32/Makefile.  That’s interesting you say.  Isn’t my configure script smart enough to indicate this is not a Windows OS so I have no need for a win32 makefile.  Interesting.  Well, in any case, we now are ready and have the makefiles.  Makefiles, in that it looks like rather than one grand file, we have a bunch of smaller makefiles, organized by directory.  That’s nice, always good to split things up a little.

In your best Staples impression.. “That was easy”.

Finally, let’s install this.  From the two lines covering the install in our O’Reilly manual, we need to su to root - but you knew that already, from installing pcre right?  Excellent!

Still as root, we execute snort using our standard test, which is to print out the version:

#snort —version

This time, everything works and we are off and running!

Now, hold on a minute.  Surely you want to be able to do more with snort than print the version number, cool as that may be?  Well, it turns out we need to configure a few more things.  Snort is very nice in that you can do a minimal install (no web server, no database), but you do need some rules, and those are now a separate install.

Installing the Rules

So let’s grab a copy of the rules.  You need to be a paying subscriber in order to get the most recent rules, but as a registered user, you can get the rules for free thirty days after they are released.

Now that you are a pretty familiar with Unix, we’ll introduce a couple more to help us easily install the rules all from the shell.  The rules are downloaded with the suffix of “gz”, meaning it is a compressed tar file.  So from the shell, in your download directory, execute the following command:

gzip -d snortrules-snapshot-xxxx.gz

This unzips the file and you’ll have a file with the same name, except with the “tar” suffix, which stands for “tape archive”.  A tar file is basically a bunch of files packaged together in one file.

Now copy this file to your base snort directory, and we’ll execute the following command, which will add all the files and directories from the tar file to your current directory.  The -x stands for “eXtract”, v for verbose, and f to indicate the file is the next argument.

tar -xvf snortrules-snapshot-xxxxtar

now you should have a “rules” directory,  Browse a few of the rules to see the structure and how they work.

Now we can really put snort through it’s paces.

Let’s try this simple command from the Snort manual:

snort -v

Halt little pot, halt!

We stop the process in the usual way, with ctrl-z.  Note this is not the command key, but the control key.  A summary will print out, showing a few statistics that were collected while snort was running.

Let’s use netstat to get a little idea about which IP addresses are which:

netstat

Installing the Rules

Per the manual, we can test the configuration with the following command:

sudo -T -c ~/Development/snort-xxx/etc/snort.conf

ERROR: parser.c(5165) Could not stat dynamic module path “/usr/local/lib/snort_dynamicrules”: No such file or directory.

Open up snort.conf and find the section on dynamic rules.  We’re not exactly sure what’s breaking, so copy each directory or file and see if it exists:

ls /usr/local/lib/snort_dynamicpreprocessor/

Ok, everything’s fine except the last line:

# path to dynamic rules libraries

dynamicdetection directory /usr/local/lib/snort_dynamicrules

Hm, we did install a directory called “so_rules” when we downloaded the rules, but that’s for the shared objects, and here it looks like we need the actual rules themselves.  Instead of Googling, let’s do a “smart” search, searching directly for snort_dynamicrules on the Snort.org site.  About four links are returned for this search.  Here’s an interesting link:

http://www.snort.org/snort-rules/about-so_rules

This article states:

This command tells snort to use the snort.conf file where it will find the dynamic rule files (thanks to the configuration options above) and then use those files to generate the stub files and put them into /usr/local/etc/snort/so_rules/

After this is complete, the rule files appear in the directory.

# ls /usr/local/etc/snort/so_rules/

We’ve already got the stub files in the right location, so perhaps we can comment out the line that is breaking.  One other thing we see from this article is that the snort.conf defines a bunch of includes for the dynamic library rules, and in our snort.conf these are commented out, so, now that we’ve verified we actually have the files, we can uncomment them.  It might be start to try one change at a time, rather than making both changes, but let’s see what happens.  We comment the line out, and add a comment to indicate the change we made in case we have to roll it back later.  We also uncomment the last lines in snort.conf, where the includes are defined.

#MOK 2010-Sep-14 Comment out line below since no such directory

# and we already have stub files created

#dynamicdetection directory /usr/local/lib/snort_dynamicrules

[snip]

# dynamic library rules

# MOK - 2010 Sept 14 - uncomment

include $SO_RULE_PATH/bad-traffic.rules

[etc]

Excellent!  Snort is able to get much farther in processing the snort.conf, but it still fails with a new error.  Again, not the nice error message, giving us a line number and an error message in English, instead of something like “NullPointerException”.

ERROR: ./snort.conf(195) => Invalid keyword ‘compress_depth’ for ‘global’ configuration.

Fatal Error, Quitting..

Back to the snort search.  This time only one link is returned, which is a link to the Snort manual.  In the manual, we find the following:

[compress_depth <num>] [decompress_depth <num>] \ disabled

For some reason, our build seems to not understand compress_depth.  We observe that this can be disabled, so maybe it can be removed without any ill effects, but that should be the last option.

Instead, googling tells us we needed to run configure with the enable-zlib argument:

./configure —enable-zlib

Before making that change, while we have the snort.conf open, there are a couple minor tweaks we can make.  We note that somehow the stream5_tcp policy setting is set to “windows”, we see from the README.stream5 that this can be changed to “macos”.  Similarly, the frag3_engine is set to “windows”, we see from the associated readme file this should be changed to “first”.

Then run the makefile again, making sure to “clean” so that the complete build will be done.  Otherwise, Make is smart enough (or lazy and dumb enough, depending on your perspective), not to waste time recompiling any files it doesn’t think it needs to.  And only some scripts changed, like the makefile, and none of the source files changed, nothing will get built and the compile will run very quickly.  Ordinarily, if you only change a file or two, this is what you want to happen, but not in this case.

make clean

Now you are ready to install, and this time it does work successfully, so we are *finally* ready.  According to the O’Reilly book:

sudo snort -Dd -l /private/var/log -A console -c ~/Development/snort-2.8.6.1/etc/snort.conf

A brief description of the arguments:

We are executing Snort with “sudo”, which allows Snort to run with Administrator privileges.  [EDIT: Per Martin’s e-mail, as a security item, should drop admin privileges, once we have everything configured.  For one thing, we need to set up a log directory that Snort can write to without root privilege.]

The -D tells snort to run in “daemon” mode, so it runs as a background process.  Even if you log out, Snort will continue to run until you shut off the computer.

The -l tells Snort where to send the logs

-c tells Snort to use the configuration file we’ve updated to fix a few minor items

Instead of printing the startup information to the console, the output will now be directed to the system log.  A good way to browse the logs is to use the Console application, which can be configured the same way as you set up the Terminal application.  Under /private/var/log, you should now see the Snort logs.  If permissions are not set correctly, you will see a message that says “You do not have permissions to read this file” and the display will be blank.  Also note that the logs are in binary format by default.

(Another useful log is the “secure” log.  This tells you security events, such as if someone tried to run su but failed.)

If you go to a shell, you can use the tcpdump utility to view the logs:

tcpdump -r snort.log.xxx

The Grand Conclusion

And that is the mere tip of the iceberg.  Start with the manual above, or a good book like the O’Reilly Snort Cookbook, or Brett D. McLaughlin’s article on configuring Snort, Richard Bejtlich’s excellent Snort Report series, and continue from there.

Happy Snorting!