Re: RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install issue (UNCLASSIFIED)

["Wright, Jonathon S CTR (US)" <jonathon.s.wright.ctr () mail mil>]

Classification: UNCLASSIFIED
Caveats: NONE

Thanks for the feedback, this is great information. 

> 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.

Good tip. I'm a BSD guy, so the ports tree did all this for us, we had to
build from source maybe .01% of the time. 

> 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.

Yeah good tip here too.  We saved off our ./configure command as it took a
while to determine the right arguments we needed =)

> 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.

We did talk with Red Hat they indicated as you did in the last question,
"Our model is designed for a stable server, not a bleeding edge one". They
also indicated that an rpm would not be created for the reason you stated,
RHEL 7 is practically here. 

I noticed that CentOS had an rpm (on the snort.org site no less). Is that
one viable? If so, whats the best way to remove the current install of snort
(and its dependencies if necessary) since it was built from source? 


> 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.


Yeah, I read through the change log, it literally has hundreds of changes,
averaging 40 or so per minor revision i.e. 8.33 to 8.34 changelog has 44
fixes / enhancements. If possible, I'd really like to keep the latest
version, so I'll see what I can do. 



> 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!

Appreciate that tip, I'll keep that one in mind!


> 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.

This part is very interesting. Since my configure - make - make install
skills are very low I'll need to do some research in how the --prefix option
works with configure, specifically snort. And then how to apply that so that
I have a step by step on making snort use the latest pcre libraries. I would
assume I'd have to determine where the pcre compiled files (*.so*) went when
I executed the simple ./configure, make, make install. Then I'd know where
to point snort too with the --prefix option. 

The last part about a pinch is interesting too. I'll need to do some
research on the CFLAGS (environment variable or snort variable?) and what
else uses it, and perhaps how to just set it in the .profile of the user
that normally starts up snort. 


 
> 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 :)

Yeah, it was a long hard battle. We (I work for the DoD) have to move from
FreeBSD to Red Hat because of a FIPS 140-2 compliance issue with
FreeBSD...Red Hat was the only allowable OS (or Windoze, haha). 


Thanks again for the information!


JW

-----Original Message-----
From: Joshua Kinard [mailto:kumba () gentoo org] 
Sent: Friday, December 27, 2013 11:05 AM
To: Wright, Jonathon S CTR (US); snort-devel () lists sourceforge net
Subject: Re: [Snort-devel] RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install
issue (UNCLASSIFIED)

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 2.9.5.6 
> / 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 :)

--J

Classification: UNCLASSIFIED
Caveats: NONE

Attachment: smime.p7s
Description:

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk

_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!