[Snort-devel] RHEL 6 with Snort and PCRE 8.33 install issue (UNCLASSIFIED)

Joshua Kinard kumba at ...2185...
Fri Dec 27 16:05:21 EST 2013

On 12/27/2013 3:24 PM, Wright, Jonathon S CTR (US) wrote:>
> So here are my 5 questions:
> 1. Is the guide I followed (above url) the best way to build snort or is 
> there a better guide? (has anyone else done RHEL 6 / snort / pcre
> 8.33)

I haven't tried this on RHEL6...yet, but I have done it on RHEL5.  It's not
difficult if you're somewhat familiar to building stuff from source a lot.
I actually maintained my own local Snort copy in my user $HOME because I
lacked admin rights to that box.

Quick tips:

1. Always run ./configure --help and read through the Snort-specific
parameters (GNU autoconf has default --config-options it includes in
virtually everything -- you can skip these, like --prefix, --with-gnu-ld,
etc).  You'll spend the most time here.

2. Snort's make system is fairly non-complicated.  Assuming you ran
./configure with the options you wanted (and any optional $CFLAGS), a basic
"make" will compile stuff for you, followed by "make install".

3. Save your ./configure command lines in a text file.  Next time you update
one of Snort's dependencies, just re-use the old ./configure line from the
last build, making sure to see if a newer Snort rev has new options in its
./configure --help that might be worth adding.

> 2. Why is snort not available for RHEL 6 as an rpm or provided in any 
> RHEL repository? This is going to be a maintenance nightmare if 
> everything has to be built from source everytime a new version is 
> released (we have large number of servers).

You'll have to ask that question to Red Hat directly.  You can try filing a
bug with them and see if they'll roll an RPM/SRPM for it (although, I
seriously doubt this will happen for RHEL6 -- possibly whatever becomes
RHEL7).  Also check to see if CentOS has any RPMs available, since CentOS 6
will match RHEL6 exactly for the core packages, and then they sometimes roll
their own extras on the side that should play nice w/ RHEL6.

> 3. What is the impact of not having pcre 8.34? (40% of our rules use
> pcre expressions)

Possibly just additional optimizations to the pcre language.  95% of the
pcre you'll use in a Snort rule is the standard stuff that we've all been
using.  You'll have to read through the Changelog for the pcre code to see
what specific has been changed.

As for your 40% usage of pcre, Snort offers a lot of ways to optimize rules
so that you only enter the pcre engine as a final check on a packet to weed
out false-positives.  Make sure you're taking advantage of the fast-pattern
matcher (especially fast_pattern:only;) and putting your discrete option
keywords at the front of the rule!

> 4. How do I compile / force snort to use the new pcre libraries if #3 
> above is severe?

As long as you compiled the pcre source and put it in a directory that's in
your include path, Snort's configure script should detect and use it
automatically.  Usually, if you specified --prefix to one package's
configure script that Snort depends on, you'll need to pass the same
--prefix to Snort's configure script as well so that the configure script
sets all the include paths up right.  In a pinch, you can specify your own
via CFLAGS -I/path/to/custom/includedir and -L/path/to/custom/libdir.

> 5. Can I have to leave 2 versions of pcre (one for OS and one for Snort)
>  on the OS? If so how do I repeat #4 above when a new version of snort /
>  pcre comes out?

That is possibly a lot harder.  Usually, a library will install
version-specific files into /lib{32|64}, then create symlinks for older
versions or non-versions to point to the latest copy.  I.e., /lib/libc.so.6
is a symlink to /lib/libc-2.xx.so.  It varies from package to package, but
some packages are very good at allowing you to have multiple versions
installed simultaneously.  Yet, others are a lot more difficult (usually
because their "make install" overwrites existing files)

Remember, you run RHEL6 because they provide a long-term stable baseline and
have a support contact number (in exchange for contract $$$).  If you want
to run bleeding edge, get the necessary approvals/paperwork in place and
then look into Debian's "sid" branch or Gentoo :)


More information about the Snort-devel mailing list