Re: Snort 2.9.7.2 and barnyard2 1.13 on RHEL via RPM

[Tomas Hajek <hajek () oakland edu>]

Hi Tawanda,
   Thanks for the information, in my searching I had not come across that
post yet.  However, I already solved the problem regarding -A and -b as
mentioned in my email.  I see in the post you mentioned that the reason it
works there (and did not for me) is that they modified the barnyard2 init
script to look in /var/log/snort/ for the unified2 log and not in a
subdirectory specific to the interface (which is what both the master
branch and v2.1.13 specify in the init script).  I think that in the post
that if they planned to use multiple interfaces on the same server then
this config might be problematic as it would have multiple interfaces
getting logged to the same file but perhaps I am wrong in that.   Note also
that I am not be logging to snort.u2 nor would barnyard2 be reading from
that file based on the link you mention.   That post and my configuration
outputs the unified2 data to merged.log.<timestamp>.

  My output unified2 line looks like the following in /etc/snort/snort.conf
output unified2: filename merged.log, limit 128

   What I am trying to come up with is a maintainable and repeatable
installation process.  When I am fully completed with my project it will
most likely have more than a dozen snort sensors and they will most likely
be installed over months to years and in some instances will be using a
single interface and in others will have multiple interfaces.
    As a general rule when we install software on our Linux servers we try
to do it with a package manager. The future plan is to have our own local
yum repository on a Red Hat Satellite server and tie that into our
kickstart build process.  This allows any admin to be able to kickstart a
new sensor with minimal effort and allow to review and update software on
the systems in a consistent and repeatable way which is important to us to
maintain auditable systems.   It should also allow for upgrades for example
to barnyard2 when version 1.14 is released with a simple yum update.  Since
the snort and barnyard2 projects both provide either source rpm or rpm spec
files I'm assuming that using them in a packaged form is desirable (it is
to me at least).

   My current steps look something like the following although I am still
working on some issues:
# For DAQ
sudo yum install libpcap-devel.x86_64
wget https://www.snort.org/downloads/snort/daq-2.0.4.src.rpm
rpmbuild --rebuild daq-2.0.4.src.rpm
sudo yum install ~/rpmbuild/RPMS/x86_64/daq-2.0.4-1.x86_64.rpm

# For Snort
sudo yum install pcre-devel
wget
http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
sudo yum install epel-release-6-8.noarch.rpm
sudo yum install libdnet libdnet-devel
sudo yum install zlib-devel
rpmbuild --rebuild snort-openappid-2.9.7.2-1.src.rpm
sudo yum install ~/rpmbuild/RPMS/x86_64/snort-2.9.7.2-1.x86_64.rpm

# For Barnyard2
sudo yum install mysql-devel
mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
wget https://github.com/firnsy/barnyard2/archive/v2-1.13.tar.gz
tar -zxvf v2-1.13.tar.gz
mv barnyard2-2-1.13 barnyard2-1.13
cd barnyard2-1.13/
./autogen.sh
./configure --with-mysql --with-mysql-libraries=/usr/lib64
--with-mysql-includes=/usr/include
cd ..
tar -czf ~/rpmbuild/SOURCES/v2-1.13.tar.gz barnyard2-1.13
rpmbuild -bs barnyard2-1.13/rpm/barnyard2.spec
rpmbuild --rebuild --with mysql
~/rpmbuild/SRPMS/barnyard2-1.13-1.el6.src.rpm
sudo yum install ~/rpmbuild/RPMS/x86_64/barnyard2-1.13-1.el6.x86_64.rpm
## Note that the BARNYARD_OPTS arguments in the barnyard2 init script
specify '-L' which is not valid, the master branch changes this to '-l' so
I pulled the init script from the master branch.

   I see one potential follow-up question here which is what version of
barnyard2 are you using with snort version 2.9.7.2.  Should I use the
master branch or a version tag?  I chose 1.13 because it seemed to fix a
lot of bugs from the 1.10 stable release and I did wind up pulling the init
script from the master branch since the change was minimal.  I'd prefer not
having to change pieces that are not configuration files ( Note, I do not
consider and init script to be a config file).

thanks,
 -Tomas


On Wed, Apr 15, 2015 at 2:22 AM, Tawanda Purazi <Tawanda () tsi co za> wrote:

> Dear Tomas,
>
>
>
> I had the same problem and it was resolved by setting “BINARY_LOG=0” in
> /etc/sysconfig/snort and restarted snort.
>
> See this article:
>
>
>
>
> https://cyberoperations.wordpress.com/class-archives/2013-class/09-mysql-5-1-barnyard/
>
>
>
>
>
> especially the section…..
>
>
>
>
>
> If you include the switch -A full, snort appears to change the file name
> it uses for its output. The -A switch determines the alert mode, and can be
> set to full, fast, or none Interestingly, I found that no matter which of
> those choices you make, the name of the output file changes to snort.log.
> We can handle this problem by commenting out line 69 in
> /etc/sysconfig/snort so that portion of the file reads
>
>
>
> # How should Snort alert? Valid alert modes include fast, full, none, and
>
> # unsock.  Fast writes alerts to the default "alert" file in a single-line,
>
> # syslog style alert message.  Full writes the alert to the "alert" file
>
> # with the full decoded header as well as the alert message.  None tu#rns
> off
>
> # alerting. Unsock is an experimental mode that sends the alert information
>
> # out over a UNIX socket to another process that attaches to that socket.
>
> # -A {alert-mode}
>
> # output alert_{type}: {options}
>
> #ALERTMODE=full
>
> This almost solves the problem. We also cannot use the -b switch to
> specify tcpdump format for the logs. Modify line 81 of /etc/sysconfig/snort
> so that portion becomes
>
>
>
> # Should Snort keep binary (AKA pcap, AKA tcpdump) logs also? This is
>
> # recommended as it provides very useful information for investigations.
>
> # -b
>
> # output log_tcpdump: {log name}
>
> BINARY_LOG=0
>
> If you make these changes to /etc/sysconfig/snort then restart it, it will
> now correctly send its results to the files /var/log/snort/snort.u2
>
>
>
>
>
> Good lucky,
>
>
>
> Tawanda
>
>
>
>
>
> *From:* Tomas Hajek [mailto:hajek () oakland edu]
> *Sent:* 14 April 2015 22:18
> *To:* snort-users () lists sourceforge net
> *Subject:* [Snort-users] Snort 2.9.7.2 and barnyard2 1.13 on RHEL via RPM
>
>
>
> Hello Everyone,
>
> I have barnyard2 1.13, snort 2.9.7.2, working on Red Hat Enterprise Linux
> 6.6 installed via rpms.
>
> I am running both barnyard2 and snort using their typical config files
> snort.conf and barnyard2.conf but also with the RHEL way of using sysconfig
> and init scripts.
>
> I had many problems initially getting unified2 logging to work but finally
> came to what I believe to be the underlying issue.  This was after running
> through the removal of -A and -b, for specifics I mean modifying the
> parameters in /etc/sysconfig/snort to set the following:
> BINARY_LOG=0
> ALERTMODE=
>
> The larger problem for me seems to be the init scripts.  For barnyard2 it
> assumes a log directory of /var/log/snort/$INTERFACE where $INTERFACE is
> the name of the network interface (e.g. eth0, or eth1).  The snort init
> script seems to make a special case of running snort on a single interface
> and as such logs to /var/log/snort/ with a single interface and
> /var/log/snort/$INTERFACE/ when multiple interfaces are specified in the
> sysconfig file.  This means that when I have only 1 network interface
> configured, snort is writing the merged.log to /var/log/snort/ but
> barynard2 expects it to be in /var/log/snort/eth0/.
>
> I tried to change the value of LOG_FILE in /etc/sysconfig/barnyard2 to
> ../merged.log or /var/log/snort/merged.log but it appears that that
> variable is stripped down to just the filename so I can't seem to fix it
> with that.   I also noted that barnyard2 also expects a timestamp to be
> appended to the unified2 log (so unified2 logging also needs to have
> nostamp removed in /etc/snort/snort.conf default config ).
>
> I confess that I am a new user of snort and barnyard2 and this had me
> stumped for a day or two and I am wondering how others are maintaining
> snort and barnyard2 on a RHEL system with RPM installs?
>
> Has anyone experience the same that I have?
>
> Have I missed something obvious or is my assessment above correct?
>
> I admit at the moment I just added a second interface to snort and now
> have snort and barnyard2 logging and reading from the same corresponding
> directories ( /var/log/snort/eth0 and /var/log/snort/eth1) but is there a
> way to get this to work properly with just one interface?
>
>
>
> Any advice would be appreciated.
>
> thanks,
>
>  -Tomas
>
> --
>
>
>
>                 Tomas Hajek
>
>                 hajek () oakland edu
>
>                 1-248-370-3505
>
>                 Senior Linux Systems Engineer
>
>                 University Technology Services
>
>                 Oakland University



-- 

                Tomas Hajek
                hajek () oakland edu
                1-248-370-3505
                Senior Linux Systems Engineer
                University Technology Services
                Oakland University

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!