Re: Barnyard2 fatal error duplicate references, but there are no duplicates

[elof () sentor se]

On Thu, 1 Nov 2012, beenph wrote:
> > I ran barnyard2 in testmode, but it bails:
> > barnyard2 in self-test mode:
> > barnyard2 -T -v -c barnyard2.conf -d /log -f snort.unified2 --pid-path /var/run
> > Found pid path directive (/var/run)
> > Running in Test mode
> >
> >          --== Initializing Barnyard2 ==--
> > Initializing Input Plugins!
> > Initializing Output Plugins!
> > Parsing config file "barnyard2.conf"
> > Found pid path directive (/var/run)
> > WARNING database: Defaulting Reconnect/Transaction Error limit to 10
> > WARNING database: Defaulting Reconnect sleep time to 5 second

1)
What are these two warnings?

2)
When I see 'WARNING' in capital letters, I tend to think it is something 
serious. If this warning is just a "for your information"-message, could 
you please change it to 'Notice:' instead of 'WARNING'?


> > Checking PID path...
> > PID path stat checked out ok, PID path set to /var/run
> > Writing PID "45577" to file "/var/run/barnyard2_mon0.pid"
> > Chroot directory = /var/log/snort
> > ERROR database: Query [SELECT ref_id FROM reference WHERE ref_system_id = '7' AND ref_tag =
> > 'blog.fireeye.com/research/2010/10/feodosoff-a-new-botnet-on-the-rise.html#more';]
> > returned more than one result
> > [SystemCacheSynchronize()], Call to ReferencePopulateDatabase() failed
> > [CacheSynchronize()]:, SystemCacheSyncronize() call failed.
> > ERROR: database [DatabaseInitFinalize()]: CacheSynchronize() call failed
> > ...
> > Fatal Error, Quitting..
> > Done. Cleaning up.
> >
> > There's just one result, so why do barnyard2 complain about "returned more
> > than one result" ?
>
> The database cache synchronize call appens in a transaction, thus if
> something fail you will not have altered data
> inserted in your database so this is normal.

Ok. Perhaps your errormessage should state that _some_ query in the 
transaction failed with "returned more than one result", and that the one 
printed is just an example, not neccessarily the one generating the error.


> > 1)
> > Should there only be only ONE 'www.f-secure.com/weblog/archives/00002227.html'
> > in the database, and the signatures 2013481, 2013482 and 2013483 should
> > all reuse it, not having their own ref_id instance?
> Exact, there is no need for duplicates.

Good.


> > 2)
> > In the new barnyard2.1.10, you seem to have added some kind of
> > pre-population of the reference system.
> > Does this mean that there's no longer any need to pre-populate it using a
> > separate system?
> > If so that would be great - one system less to deal with.
> > Also, if I'm correct in my assumptions above, the problem should not
> > appear at all.
> Yup it will populate all the required information like 2-1.9 did and
> snort database output plugin also did.

That sounds great!
Before I disable my pre-population functions, I must ask:

Does the new barnyard2.1.10 deal with the problem with two sensors 
detecting the same data simultaneously?

Example:
The reason why pre-population is/was neccessary in the first place was 
when you have a database without the metadata pre-populated.
So when two sensors, A and B, both see the same malicious packet X, they 
both ask the database:
A: do metadata for X already exist in the database?
B: do metadata for X already exist in the database?
The database replies to both A and B: no
So both A and B continue, and both of them insert the metadata (and then 
the eventdata).
Some minutes later, X happen again.
A: do metadata for X already exist in the database?
B: do metadata for X already exist in the database?
The database replies to both A and B: yes, more than one result
So neither A nor B will log the X-event. And won't log any X-events at all 
until the duplicate issue is fixed.

So, does the new barnyard2.1.10 handle this better?
You say that barnyard2 will pre-populate all metadata itself, so I 
hope/guess this means that the above scenario can not happen.

/Elof

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
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!