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:

[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

[Jim Hranicky]

Just wondering, will 2.2 also support tagged packets?

Thanks,

--
Jim Hranicky
IT Security Engineer
UF Information Technology
105 NW 16TH ST Room #104 GAINESVILLE FL 32603-1826
352-273-1341
Office of Information Security and Compliance

--

---
You received this message because you are subscribed to the Google Groups "barnyard2-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to barnyard2-dev...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[beenph]

On Fri, May 10, 2013 at 9:51 AM, Jim Hranicky <phra...@gmail.com> wrote:
> Just wondering, will 2.2 also support tagged packets?
>

Hi Jim,

Absolutlely, tagged packets anchored to an event is an essential part of some
signature and allow a better understanding of the triggering event.

So they will be there.

-elz