Barnyard2 2-1.13-BETA

[beenph]

Greetings everyone,

We are happy to announce the Availability of Barnyard2 2-1.13-BETA
which can be downloaded from HERE: https://github.com/firnsy/barnyard2.git


This release is a bug fix release that also introduce a few new
features and enhancements


=====================
UPGRADING REQUIREMENT
=====================
----------------------
If you are upgrading to barnyard2 2-1.13 Build 325 or above from a
previous version that is not 2-1.13 and using the output database.

***** We highly recommend ******
To delete every row in your sig_reference table. (DELETE FROM sig_reference;)
The table will be re-populated at process startup, and has no impact
on historical data.
----------------------
=====================
UPGRADING REQUIREMENT
=====================





Feature request:
----------------
Phil Daws: Add interface and hostname field to spo_alert_csv if
specified.
Jorge Pinto: spo_syslog_full support for ASCII,BASE64 payload

Jason Brvenik: variables .....(a long time ago, sorry :P)

Martin Olsson: Remove some useless verbosity unless
./configure --enable-debug is specified and proper
flag are used (spo_database and sid-msg.mapv2)

*And all other barnyard2 users who help and contribute.

Bug report:
-----------
Martin Olsson: - bug in sig_reference generation and good
discussions.

John Eure and others - autogen.sh could cause some issue on some system so
[autoreconf -fv --install] is
not set to autoreconf -fvi

John Naggets - spo_database: could stop barnyard2 from
processing new event if some
packets with ip
option where processed and
option_len was null.

Fäbu Hufi - spo_syslog_full: in complete mode was
printing wrong ip version
information and ip header length.

*And all other barnyard2 users who help and contribute.


New feature:
------------


Support for sid-msg.map Version 2 format.
-------
A new sig-msg.map format can be generated by pulledpok (upcoming release,
already in svn). Detection of sid-msg.map version is done by a simple
header in the file that shouldn't be altered if you want it to be
processed correctly.

sig-msg.map version 2 format extend the information already present in
the sid-msg.map file created from rules.

This new format version allow signature pre-population if users are
using output database method with barnyard2 2-1.13 and above.
______________________
sid-msg.map v1 format:
______________________
SID || MSG || REF 1 || REF N
sid := integer
msg := string
ref := string
______________________
sid-msg.map v2 format:
______________________
GID || SID || REV || CLASSIFICATION || PRIORITY || MSG || REF 1 || REF N
gid := integer
sid := integer
rev := integer
classification := string (if NULL set to NOCLASS)
priority := integer (if prio == 0, classification priority is used)
msg := string
ref := string
=====================
generator (GID, gen-msg.map) are defaulted to the following value
if their information is not overruled in sid-msg.map v2 file via
processing of preprocessor.rules:
revision 1
classification 0
priority 3
If generator message is present in the sid-msg.map v2 file, and
gen-msg.map message are longer
(more comprehensive by string length),
gen-msg.map messages are used instead of sid-msg.map v2 file
generator messages.
=====================
-------


Signature/event logging suppression at spooler level
-------
Read doc/README.sig_suppression
configuration file Variables:
-------

Barnyard2 configuration Variables
-------
You can now use [var VARNAME value] in the barnyard2 configuration
file and every
instance of $VARNAME will get replaced by value.
Note that variable declaration order is important only you include a
variable in a variable.
EX (is VALID):
var INTERFACE ethX
var PATH /var/log/IDS
var LOG $PATH/$INTERFACE/log
var ARCHIVE $PATH/$INTERFACE/archive
EX (is INVALID):
var LOG $PATH/$INTERFACE/log
var ARCHIVE $PATH/$INTERFACE/archive
var INTERFACE ethX
var PATH /var/log/IDS
-------

new output database configuration keyword
-------

Keywords connection_limit and reconnect_sleep_time where added in
2-1.10 but where "undocumented" and shouldn't be modified unless
you encounter connectivity issue.

connection_limit <integer>: default 10 - The maximum number of time
that barnyard2 will
tolerate a transaction
failure and or database
connection failure.

reconnect_sleep_time <integer> : default 5 - The number of seconds to sleep
between connection retry.

disable_signature_reference_table - Tell the output plugin not to synchronize
the sig_reference table in the schema.
This option will speedup the process,
especially if you use sid-msg.mapv2
file or have a lot of signature already
in databases. (Make sure that you
do not need that
information before enabling this)
-------


Enjoy and do not hesitate to send feedback/suggestion/feature request.

The barnyard2 team.

[beenph]

Sorry for the noise.

 

But i forgot to say that if there is no  issue found,

we will remove beta tags and make it a release for
April 24. 2013.

*****************

 

-elz

 

[beenph]

Greetings Everyone,

We did commit a little fix/feature add in 2-1.13-BETA (Build 326)

It has been asked by quite a few users to enable SIGHUP,SIGUSR1 to be
available for barnyard2, well this time has come.

It also fixes a few minor issue, error compiling when --enable-debug
was used, fixes a few literals, fixes rpm spec file (for future
release).

While its currently not upstream it will get when tested, thus I
encourage people who would like to give it a HUP trust to
try it out, especially people who update their signature often.

Source tree: https://github.com/binf/barnyard2/tree/fix-signals

Commit message:
<SNIP>
Last minute commit for a long waited needed feature and some little fix. …

Add: Support for proper signal handling.

Fixed: Compile issue when debug was enabled (missing , in some
DEBUG_WRAP code.

Fixed: Changed a few places where the snort literal was used instead of
barnyard2 and this could confuse some first time barnyard2 users.

Fixed: RPM spec file to point to good version (when needed)

Bumped: Build to 326
</SNIP>

Cheers,

-elz




On Wed, Apr 10, 2013 at 8:52 AM, beenph <bee...@gmail.com> wrote:

[Michael Steele]

It's failing to compile under CygWIN :(

Best regards,
Michael...

WINSNORT.com Management
--
****************** Established ~ 2001 *******************
*          Visit Us @ http://www.winsnort.com           *
* Windows Intrusion Detection System (WinIDS) *
*  ~~ FREE Snort Guided Installs & Support Forums ~~    *
* Snort: Open Source Network IDS - http://www.snort.org *
*********************************************************

--

---
You received this message because you are subscribed to the Google Groups
"barnyard2-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to barnyard2-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Michael Steele]

After deleting all the folders and starting over from scratch,
Barnyard2-1-13-BETA-325 now builds on CygWIN.

[Rich Rumble]

On Fri, Apr 26, 2013 at 1:11 PM, Michael Steele <mich...@winsnort.com> wrote:

After deleting all the folders and starting over from scratch,
Barnyard2-1-13-BETA-325 now builds on CygWIN.

I did d2u * and then autogen worked.
-rich

[Michael Steele]

I’m not sure what you are asking?

 

I did d2u * and then autogen worked.

 

Do I need to do something else? I’m actually not running the beta or releasing it. I was just trying to compile MySQL 5.6.11, which so far looks like a failure under CygWin.

 

Best regards,

Michael...

--

[Rich Rumble]

On Fri, Apr 26, 2013 at 1:22 PM, Michael Steele <mich...@winsnort.com> wrote:

I’m not sure what you are asking?

 

I did d2u * and then autogen worked.

 

Do I need to do something else? I’m actually not running the beta or releasing it. I was just trying to compile MySQL 5.6.11, which so far looks like a failure under CygWin.

This is the wrong list for MySQL compile errors. I was referring to barnyard autogen not running at first

./autogen.sh
./autogen.sh: line 6: syntax error near unexpected token `elif'
'/autogen.sh: line 6: `elif which glibtoolize > /dev/null; then

That was the By2 issue I had, then running dos2unix autogen started working. I'm moving to MariaDB instead of MySQL, I'm curious if it will work with By2 so I'll let you know this weekend.
-rich

[beenph]

On Fri, Apr 26, 2013 at 12:14 PM, Michael Steele <mich...@winsnort.com> wrote:
> It's failing to compile under CygWIN :(
>

Hi Michael,

What is not working?
Can you add some juice to your e-mail when you state something is not working?

Because even after reading Rich replies, im still not getting what is
not working.
Thanks you.
-elz

[Michael Steele]

The compile failed because it got confused about file locations. Removed all
the folders, and rebooted. Everything compiles normal on the latest BETA
version under CygWin on Windows.

I was confused about the response I got back from Rich.

----------\

I did d2u * and then autogen worked.

-rich
----------/

The only problem I'm having now is; All versions of MySQL past 5.5.30 fails
to compile. It appears that the MySQL team is not concerned about their
software compiling under CygWin (low priority).

If I compile MySQL 5.5.30 under CygWin it creates a file called
cygmysqlclient-18.dll . Do you know if I can just compile Barnyard2 using
MySQL 5.5.30, but include the latest stable binary release of MySQL with my
software pack?

Not sure what the differences could be in the cygmysqlclient-18.dll file
from version to version for MySQL.

PostgreSQL has no problem compiling from version to version.

Best regards,
Michael...

WINSNORT.com Management
--
****************** Established ~ 2001 *******************
*          Visit Us @ http://www.winsnort.com           *
* Windows Intrusion Detection System (WinIDS) *
*  ~~ FREE Snort Guided Installs & Support Forums ~~    *
* Snort: Open Source Network IDS - http://www.snort.org *
*********************************************************

-----Original Message-----
From: barnyar...@googlegroups.com
[mailto:barnyar...@googlegroups.com] On Behalf Of beenph

Sent: Friday, April 26, 2013 5:15 PM
To: barnyar...@googlegroups.com
Subject: Re: [barnyard2-users] Re: Barnyard2 2-1.13-BETA

[beenph]

On Fri, Apr 26, 2013 at 7:21 PM, Michael Steele <mich...@winsnort.com> wrote:
> The compile failed because it got confused about file locations. Removed all
> the folders, and rebooted. Everything compiles normal on the latest BETA
> version under CygWin on Windows.
>

Which compile? barnyard2?

>
> The only problem I'm having now is; All versions of MySQL past 5.5.30 fails
> to compile. It appears that the MySQL team is not concerned about their
> software compiling under CygWin (low priority).
>
> If I compile MySQL 5.5.30 under CygWin it creates a file called
> cygmysqlclient-18.dll . Do you know if I can just compile Barnyard2 using
> MySQL 5.5.30, but include the latest stable binary release of MySQL with my
> software pack?
>

just specify the path to the library using the configure option, and
make sure that
you have mysql includes installed and it should build correctly.

./configure --help | grep mysql
--with-mysql=DIR Support for MySQL
--with-mysql-includes=DIR MySQL include directory
^^^^^^ This options
--with-mysql-libraries=DIR MySQL library directory
^^^^^^ AND This options

Im sure you can figure it out, but if you uses a binary library
package then you will need to make sure
you separately uses includes from source package and probably have to
copy them over your self.

Compare installed includes from a previous version that build
correctly vs the one your trying to build,
and the number of includes you need to copy from the new source
package shouldn't so mutch different i think.


-elz

[sumit kamboj]

Does db schema currently in uses with Barnyard2 2-1.13-BETA support IPV6? Is it capable to handle to alert generated by snort in IPv6 network?

[beenph]

On Sat, Apr 27, 2013 at 11:06 AM, sumit kamboj <sumitk...@gmail.com> wrote:
> Does db schema currently in uses with Barnyard2 2-1.13-BETA support IPV6? Is
> it capable to handle to alert generated by snort in IPv6 network?
>

No
2.2 will have a new database plugin that will support the new schema
with v6 support.

We will keep the old output plugin for backward compatibility.

-elz

[beenph]

On Thu, May 9, 2013 at 7:24 PM, Jeff Kell <jeff...@utc.edu> wrote:

>
> On 4/10/2013 8:52 AM, beenph wrote:
>
> ***** We highly recommend ******
> To delete every row in your sig_reference table. (DELETE FROM sig_reference;)
> The table will be re-populated at process startup, and has no impact
> on historical data.
>

You updated to 2-1.13-BETA?

>
> I may have goofed..... :(
>
> I have had some signatures showing up in the "snort alert [x:yyyyyy:z]" format for awhile (since converting to BY2). Hoping that the above hint was a reference to clearing out the database descriptors, I did a 'delete from signature'; and a 'delete from sig_reference'; and restarted things. Now I have nothing at all in the descriptions, at least from the perspective of BASE...
>
the message was really only targetted at sig_reference, and not signature.
Unfortunately there is no way of brigning them back up unless you have
a database backup or archive of your old unified2 file.

If you do and didin't have alot of signature change in your
sid-msg.map file you could clear the database then
replay your unified2 files and you would probably have less missing signature.

> Well, I take that back... a couple have populated now...
Yhea, when signatures are not found they will gradualy get re-inserted
but your historical data might point to unassigned signature
because they where removed from the signature table.

>
>
> So should this clear itself up eventually, or have I hosed my current alerts database?
> (Please reply all, i'm not on the google groups list...)
The best way i know of to overcome that is to clear the database
compeltly and replay unified2 file you have if you archive them.

You should join the googlegroups :)

-elz