Problems executing [SELECT MAX(cid) FROM icmphdr

[Ed Stoner]

Hi All,
Yesterday one of my sensors stopped sending snort hits to the MySQL database driving base. It was working and no config changes were made at the sensor.

The error in the var log messages file I'm seeing is:

database: [SynchronizeEventId()]: Problems executing [SELECT MAX(cid) FROM icmphdr WHERE sid='131';]

When I log into the MySQL server using the account and password defined in my barnyard2 config file and run that query, I get no records returned. I've tried purging my waldo file and restarting both snort and barnyard2. Same error happens.

What is the icmphdr table for and could the empty return be my error? This was working until early yesterday. Not changes or updates were made to my knowledge.

Thanks
Ed

Sent from a mobile device.

[beenph]

This message is not a error. In 2-1.13 this message is now only
enabled in debug mode so you are probably running barnyard2 betwen
2-1.10 and 2-1.12.

Its possible that something else is causing your barnyard2 process to
stop. I would suggest that you run your barnyard2 process in console
instead of daemonized and watch closely and copy back
the complete message stack that would cause your process to exit.

-elz

[Ed Stoner]

Update: talked with our MySQL DBA and that table along with others were purged to speed up BASE. So there must be other tables that references or is referenced by that table. He's trying to put the records back and I'm going to cross my fingers.

For clearing out or archiving the database of any snort entries over a certain age does anyone have a script or set of rules that they use?

Thanks,

Ed

Sent from a mobile device.

[beenph]

On Mon, May 20, 2013 at 10:36 AM, Ed Stoner <snor...@gmail.com> wrote:
> Update: talked with our MySQL DBA and that table along with others were purged to speed up BASE. So there must be other tables that references or is referenced by that table. He's trying to put the records back and I'm going to cross my fingers.
>
> For clearing out or archiving the database of any snort entries over a certain age does anyone have a script or set of rules that they use?
>
> Thanks,
> Ed
>

icmphdr table is at the bottom of dependencies, thus nothing reference
that table all of its dependancies are upward.
Obviously if your dba decided to purge the database while barnyard2
process where running...this could have caused the exit.

If you have multiples barnyard2 running before doing any database
operation i would greatly suggest that you stop all of them.
Then perform your operation and then restart them.


As a quick rule if you want to purge events based on date you can
allways tell your dba to look at the event table

do something like

DELETE FROM data WHERE sid=XXX AND cid IN (SELECT cid FROM event WHERE
sid=XX AND timestamp <="2010-01-01 00:00:00";)
DELETE FROM detail WHERE sid=XXX AND cid IN (SELECT cid FROM event
WHERE sid=XX AND timestamp <="2010-01-01 00:00:00";)
DELETE FROM icmphdr WHERE sid=XXX AND cid IN (SELECT cid FROM event
WHERE sid=XX AND timestamp <="2010-01-01 00:00:00";)
DELETE FROM tcphdr WHERE sid=XXX AND cid IN (SELECT cid FROM event
WHERE sid=XX AND timestamp <="2010-01-01 00:00:00";)
DELETE FROM udphdr WHERE sid=XXX AND cid IN (SELECT cid FROM event
WHERE sid=XX AND timestamp <="2010-01-01 00:00:00";)
DELETE FROM iphdr WHERE sid=XXX AND cid IN (SELECT cid FROM event
WHERE sid=XX AND timestamp <="2010-01-01 00:00:00";)
DELETE FROM opt WHERE sid=XXX AND cid IN (SELECT cid FROM event WHERE
sid=XX AND timestamp <="2010-01-01 00:00:00";)
DELETE FROM event WHERE sid=XX AND timestamp <="2010-01-01 00:00:00";

Obviously you want that sid=XX to be equal to the sensor you want to
clear and you can remove it (SID) from the query if you want to clear
all sensors.As for timestamp you will want to adjust the value to
match a timestamp range you want to purge.
Note that unless you have backups of the tables or that you replay
archived unified2 files, you wont be able to recover data from such
action so be cautious.

-elz

[Ed Stoner]

The process doesn't exit. I see it reading traffic and identifying rule hits. When it goes to write I'm getting:

WARNING database [Database()]: Called with Event[0x3444ba0] Event Type [7] (P)acket [0x0], information has not been outputed.

[beenph]

You might want to check your snort.conf and validate that you are using

output unified2

and not
output log_unified2
or
output alert_unified2

-elz

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

[Ed Stoner]

Hi Eric,
    Were doing output unified2: filename snort-dag0.u2, limit 128

Thanks,
Ed

[beenph]

On Mon, May 20, 2013 at 1:00 PM, Ed Stoner <snor...@gmail.com> wrote:
> Hi Eric,
> Were doing output unified2: filename snort-dag0.u2, limit 128
>

Which version of snort?

[Ed Stoner]

2.9.4.5

Thanks,

Sent from a mobile device.

[beenph]

Well this is getting hard to follow from my side.

1st you where worried about the startup message and said you where
getting "no events"?
Then you asked how to clean the schema and then you print out

The following warning : WARNING database [Database()]: Called with
Event[0xXXXXXXXX] Event Type [7] (P)acket [0x0], information has not
been outputed.

How often do you see this warning?

Once? For Every event?

Have you tried to use u2spewfoo on your unified2 file (u2spewfoo comes
with snort when build from source).

Try to write down exactly what is wrong or seem's wrong and try giving
as mutch information as possible and from there its gonna be easier to
get to the next step.

Have a good day,
-elz

[Ed Stoner]

Sorry, for the confusion. I am getting the: 

WARNING database [Database()]: Called with Event[0xXXXXXXXX] Event Type [7] (P)acket [0x0], information has not been outputed

message on every write attempt barnyard appears to be trying. I've never ran u2spewfoo before (I'm a newbie to snort), I just now ran it on the first snort log file that barnyard is processing and I can read it. 

Thanks,

Ed

Sent from a mobile device. 

[beenph]

On Mon, May 20, 2013 at 1:55 PM, Ed Stoner <snor...@gmail.com> wrote:
> Sorry, for the confusion. I am getting the:
>
> WARNING database [Database()]: Called with Event[0xXXXXXXXX] Event Type [7]
> (P)acket [0x0], information has not been outputed
>

Try upgrading the number of unified2 cache element
by setting this config directive
config event_cache_size: 8192
the default setting is 2048.

> message on every write attempt barnyard appears to be trying. I've never ran
> u2spewfoo before (I'm a newbie to snort), I just now ran it on the first
> snort log file that barnyard is processing and I can read it.
>

Its normal that you will see "things" when you run u2spewfoo but you
will need to run the following

u2spewfoo <path to your unified2 file> | grep -E "(Event|Packet|event id\:)"

Can you send me a random 20 lines if a unified2 file your trying to process?

-elz

[Ed Stoner]

Hi Eric,
I think we might have an idea what the cause is. The sensor was recently moved physically from one rack to another rack in the server room at the remote location. Since the move we are getting a high network latency. After restarting it today, it started to slowly make entries into the database. Barnyard shows in the /var/log/messages to be reading the unified snort log and is current with the incoming traffic but the entries in the database are still two days behind and not really catching up.

Does Barnyard cache it's writes to the database and keeps trying until it's successful? If so is the waiting transactions stored on the file system or in memory?

Does Barnyard update Waldo file upon a successful write to the database or before?

Should I still modify the config event_cache_size and what does that actually do for me?

Thanks for all your help.

Ed

Sent from a mobile device.

[beenph]

On Tue, May 21, 2013 at 2:51 PM, Ed Stoner <snor...@gmail.com> wrote:
Hi Ed,

> I think we might have an idea what the cause is.
> The sensor was recently moved physically from one
> rack to another rack in the server room at the remote location.
> Since the move we are getting a high network latency.

Well latency wouldn't produce the message that there is a event header
and no packets unless you are processing unified2 file logged with
alert_unified2 output or
that your event_cache_size is to small, so as for the question you asked below,
if you still get those messages, yes you might want to consider
getting the event_cache_size value.

> After restarting it today,
> it started to slowly make entries into the database. Barnyard shows in
> the /var/log/messages to be reading the unified snort log and is current with the incoming
> traffic but the entries in the database are still two days behind and not really catching up.
>

Does your event count grow's (SELECT count(*) FROM event WHERE
sid=XXX) xxx stand for your sensor id.
What type of latency are we talking about?
How many events seconds are you generating?
What type of database backend are you running?
How many processes log/read to/from your database?
Is your database virtualized or bare metal?
Alot of things can come into question at this point.
For sure the latency can be one thing but if your using
alot of ressouce to log and you didin't configure your database
backend properly it could be an issue.
Also which version of barnyard2 are we talking about here?

> Does Barnyard cache it's writes to the database and keeps trying until it's successful? If so
> is the waiting transactions stored on the file system or in memory?
>

Im not sure i fully understand the question here but once the output plugin
receive a event and a packet it will build up the transaction and
write it so you could say memory.
If you stop barnyard2 before it has written to the database the waldo
file will not be updated
and the transaction that it was trying to write will get resumed at startup.

> Does Barnyard update Waldo file upon a successful write to the database or before?
>

After all output plugins have been called the waldo file is updated.

> Should I still modify the config event_cache_size and what does that actually do for me?
>

Part of the answer is above, the event_cache_size is fixed at startup
and it caches events
while processing unified2 so if a packet that matches a previous
triggered event is seen,
the output plugin receive the event header and the matching packet.
When the cache is full and its purged, unlogged events (events without packets)
get sent to the output plugins for output.
So putting that value higher in some cases can help prevent this issue
from happening
if you generate alot of events in a short period of time, but for most setup
the default value is enough.

-elz

[Ed Stoner]

Hi Eric,
Here's a result from a ping test:

1000 packets transmitted, 1000 received, 0% packet loss, time 14012ms
rtt min/avg/max/mdev = 25.330/167.352/276.143/109.346 ms, pipe 22, ipg/ewma 14.026/260.230 ms

We have 6 sensors and this one is the only one experiencing this issue. It's writing to the database about 1 per every two seconds. We're still about two days behind. I did do the entry for the event_cache_size. I'll see if that helps. The version is 2.1.11. I'm planing on upgrading to 2.1.13 next week.  

I can't send you a sample of our snort out due to customer restrictions, but since it is entering the data into the MySQL DB (even though slowly), I  confident the snort output is ok.

Also here's info on the barnyard princess's resource usage.

top - 13:40:42 up 8 days, 16:16,  1 user,  load average: 1.11, 1.04, 1.01

Tasks: 239 total,   2 running, 237 sleeping,   0 stopped,   0 zombie

Cpu(s): 12.4%us,  0.2%sy,  0.0%ni, 87.4%id, 0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:   8048812k total,  7865480k used,   183332k free,   170924k buffers

Swap: 134217720k total,        0k used, 134217720k free,  4904900k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                 

19121 snort     20   0  330m 274m 1368 S 0.3  3.5   1:33.21 barnyard2   

Thanks,

Ed

Sent from a mobile device.

[beenph]

On Wed, May 22, 2013 at 9:45 AM, Ed Stoner <snor...@gmail.com> wrote:
> Hi Eric,
> Here's a result from a ping test:
>
> 1000 packets transmitted, 1000 received, 0% packet loss, time 14012ms
> rtt min/avg/max/mdev = 25.330/167.352/276.143/109.346 ms, pipe 22, ipg/ewma
> 14.026/260.230 ms
>
> We have 6 sensors and this one is the only one experiencing this issue. It's
> writing to the database about 1 per every two seconds. We're still about two
> days behind. I did do the entry for the event_cache_size. I'll see if that
> helps. The version is 2.1.11. I'm planing on upgrading to 2.1.13 next week.
>

At this point i would assume that your database backend is under
heavyload or reaching some kind
of limits in its current configuration, i would look that way since it
dosen't seem like like you
really have a high latency, i mean. Yes you have some latency but non
that would explain 1
event each two seconds.

event_cache_size will not help your process to insert faster btw. Its
only to prevent
what i have discribed in a previous e-mail.

> I can't send you a sample of our snort out due to customer restrictions, but
> since it is entering the data into the MySQL DB (even though slowly), I
> confident the snort output is ok.

I pasted you a command in the 6th e-mail in the thread to send me the output
on the list, the output has no private information in it thus you could
send it. I am not asking for your unified2 file at this point.


<SNIP from a previous e-mail >

Its normal that you will see "things" when you run u2spewfoo but you
will need to run the following

u2spewfoo <path to your unified2 file> | grep -E "(Event|Packet|event id\:)"

Can you send me a random 20 lines if a unified2 file your trying to process?

</SNIP from a previous e-mail >

>
> Also here's info on the barnyard princess's resource usage.
>

Princess?
I guess you meant process :P


-elz

[Marco Belmonte]

Apologies for sending out the question with the wrong subject line - I'm
not sure if I should repost my question with a new subject line for the
sake of helping those searching in the future or just accept failure of
epic proportions?

[Marco Belmonte]

Hi Firnsy, Binf and <insert Git Repo username here>,

First, thanks to all the devs who contributed code to this great project -
I appreciate you letting us animals scurry around the barnyard.

<starting oh my god help>

We recently updated to the latest stable release of Barnyard2 (2.1.13).
Here is our customary configure for your viewing pleasure:

./configure --enable-ipv6 --enable-mysql-ssl-support --enable-gre
--enable-mpls --with-mysql-includes="/usr/include/mysql"
--with-mysql-libraries="/usr/lib/x86_64-linux-gnu" LIBS="-lpcap -lpfring"

ldd shows that our binary is straight and true:

root@srvids02:/etc/snort/scripts# ldd /usr/local/bin/barnyard2

linux-vdso.so.1 => (0x00007fff4f3ff000)
libmysqlclient.so.18 => /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18
(0x00007fa70fcff000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa70fae8000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fa70f8cf000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa70f64d000)
libpcap.so.1 => /usr/local/lib/libpcap.so.1 (0x00007fa70f3f7000)
libpfring.so => /usr/local/lib/libpfring.so (0x00007fa70f1d1000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa70ee47000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fa70ec2b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa70ea26000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa70e81e000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007fa70e517000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa70e300000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa710254000)

---

We aren't sure we actually need to make barnyard pf_ring aware but since
we use it for Snort and barnyard shows it as a configure option we don't
ask questions.

Our web interface is based on Snorby - from a database perspective it's
exactly the same (innodb, etc.).

We start our snort sensors from a script - it looks like this:

/usr/local/bin/snort -c /etc/snort/snort.conf -R in1
--pid-path=/tmp/snort/in1 -l /usr/local/log/snort/in1 --daq-mode passive
-i eth1 -D &
sleep 1;
/usr/local/bin/snort -c /etc/snort/snort.conf -R in2
--pid-path=/tmp/snort/in2 -l /usr/local/log/snort/in2 --daq-mode passive
-i eth1 -D &
sleep 1;
/usr/local/bin/snort -c /etc/snort/snort.conf -R in3
--pid-path=/tmp/snort/in3 -l /usr/local/log/snort/in3 --daq-mode passive
-i eth1 -D &
sleep 1;
.
.
.
etc...etc...

We use the latest svn version of pulledpork.pl - when we update our rules
we run pulledpork like this:

pulledpork.pl -vv -P -l -c /etc/snort/pulledpork/pulledpork.conf

and our pulledpork.conf file looks like this:

###
### pulledpork.conf
### You Wanna Go Lion King?
###

rule_url=http://www.snort.org/reg-rules/|snortrules-snapshot.tar.gz|<almost
hit send>
ignore=deleted.rules,scada.rules,nntp.rules,pop2.rules,oracle.rules,server-oracle.rules,voip.rules
temp_path=/tmp
rule_path=/etc/snort/rules/snort.rules
sid_msg=/etc/snort/sid-msg.map
sid_changelog=/var/log/snort/sid_changes.log
sid_msg_version=2
sorule_path=/usr/local/lib/snort_dynamicrules/
snort_path=/usr/local/bin/snort
config_path=/etc/snort/snort.conf
distro=Debian-6-0
snort_control=/usr/local/bin/snort_control
disablesid=/etc/snort/pulledpork/disablesid.conf
modifysid=/etc/snort/pulledpork/modifysid.conf
version=0.6.1
# EOF

---

When we run barnyard - we also run it from a script and it looks like this:

#!/bin/sh

/usr/local/bin/barnyard2 --disable-alert-on-each-packet-in-stream -D -n -d
/usr/local/log/snort/in1 -f snort.u2 -X /tmp/snort/in1/barnyard2.pid -i
in1 -w /usr/local/log/snort/in1/in1.waldo -c /etc/snort/barnyard2.conf &
sleep 1;
/usr/local/bin/barnyard2 --disable-alert-on-each-packet-in-stream -D -n -d
/usr/local/log/snort/in2 -f snort.u2 -X /tmp/snort/in2/barnyard2.pid -i
in2 -w /usr/local/log/snort/in2/in2.waldo -c /etc/snort/barnyard2.conf &
sleep 1;
/usr/local/bin/barnyard2 --disable-alert-on-each-packet-in-stream -D -n -d
/usr/local/log/snort/in3 -f snort.u2 -X /tmp/snort/in3/barnyard2.pid -i
in3 -w /usr/local/log/snort/in3/in3.waldo -c /etc/snort/barnyard2.conf &
sleep 1;
.
.
.
etc...etc...

and our barnyard2.conf file looks like this:

###
### barnyard2.conf
### big lizard in my backyard
###

### 1. Global Configuration Options

config reference_file: /etc/snort/reference.config
config classification_file: /etc/snort/classification.config
config gen_file: /etc/snort/gen-msg.map
config sid_file: /etc/snort/sid-msg.map
config hostname: srvids02
config event_cache_size: 4096
config dump_payload
config verbose
config process_new_records_only
input unified2
output database: log, mysql, user=root password=<man, almost did it again>
dbname=snorby host=localhost
# EOF

---

Sorry for being so verbose - half the stuff you probably don't even need -
but I know from reading the list for the last year that most don't get in
trouble when providing too many details but the shit goes down when not
providing enough ;-)

Anywhoodles - basically barnyard launches briefly and then fails with:

May 21 12:58:15 srvids02 barnyard2[28607]: Running in Continuous mode
May 21 12:58:15 srvids02 barnyard2[28607]:
May 21 12:58:15 srvids02 barnyard2[28607]: --== Initializing
Barnyard2 ==--
May 21 12:58:15 srvids02 barnyard2[28607]: Initializing Input Plugins!
May 21 12:58:15 srvids02 barnyard2[28607]: Initializing Output Plugins!
May 21 12:58:15 srvids02 barnyard2[28607]: Parsing config file
"/etc/snort/barnyard2.conf"
May 21 12:58:15 srvids02 barnyard2[28607]: #012#012+[ Signature Suppress
list ]+#012----------------------------
May 21 12:58:15 srvids02 barnyard2[28607]: +[No entry in Signature
Suppress List]+
May 21 12:58:15 srvids02 barnyard2[28607]:
----------------------------#012+[ Signature Suppress list ]+#012
May 21 12:58:15 srvids02 barnyard2[28592]: Barnyard2 spooler: Event cache
size set to [4096]
May 21 12:58:15 srvids02 barnyard2[28592]: FATAL ERROR: [Barnyard2Init()],
Call to SignatureResolveClassification failed
May 21 12:58:15 srvids02 barnyard2[28592]: Barnyard2 exiting




I was using barnyard2 2.1.12 and I decided to upgrade the recent stable
version 2.1.13.
I downloaded the files from

https://github.com/firnsy/barnyard2.git

github repository with tag "v2-1.13"

Then I ran the following command to compile

=======================================
make distclean
./configure --enable-ipv6 --enable-mysql-ssl-support --enable-gre
--enable-mpls --with-mysql-includes="/usr/include/mysql"
--with-mysql-libraries="/usr/lib/x86_64-linux-gnu" LIBS="-lpcap -lpfring"
make -j8
make install
=======================================

Then I ran the barnyard with the following command

/usr/local/bin/barnyard2 --disable-alert-on-each-packet-in-stream -D -n -d
/usr/local/log/snort/in1 -f snort.u2 -X /tmp/snort/in1/barnyard2.pid -i
in1 -w /usr/local/log/snort/in1/in1.waldo -c /etc/snort/barnyard2.conf &

Soon after, I found that the barnyard2 process is not running.
I checked the daemon log and found the following message:

--- cut here ---

Running in Continuous mode

--== Initializing Barnyard2 ==--
Initializing Input Plugins!
Initializing Output Plugins!
Parsing config file "/etc/snort/barnyard2.conf"


+[ Signature Suppress list ]+
----------------------------
+[No entry in Signature Suppress List]+
----------------------------
+[ Signature Suppress list ]+

Barnyard2 spooler: Event cache size set to [4096]
ERROR: [Barnyard2Init()], Call to SignatureResolveClassification failed
Fatal Error, Quitting..
Barnyard2 exiting

--- cut here ---

Just to be clear, we are using sidmap v2 with pulledpork and all
classification, gen_msg, sid_msg, etc. are updated and properly processed.

Now, my partner in crime did some more investigating in an attempt to
avoid bothering all of you in helping to change our diapers - but - I
think we've shit our pants anyways.

In Barnyard2.c at line 2002...

/* Resolve classification integer for signature and free some memory */
if(barnyard2_conf->sidmap_version == SIDMAPV2)
{
if(SignatureResolveClassification(barnyard2_conf->classifications,
(SigNode
*)*BcGetSigNodeHead(),
barnyard2_conf->sid_msg_file,
barnyard2_conf->class_file))
{
FatalError("[%s()], Call to
SignatureResolveClassification failed \n",
__FUNCTION__);
}
}

... he made a few changes...

conf->classifications,
BcGetSigNodeHead()
barnyard2_conf->sid_msg_file
barnyard2_conf->class_file

... which revealed �barnyard2_conf->class_file� variable has NULL value,
so �SignatureResolveClassification� method returns 1 and our diapers get
full.

It is the strangest problem - and we are very thankful that the option to
turn to this group for help is available to us :-)

- Marco

[Marco Belmonte]

I don't know why my webmail client is filtering out the last part of my
message but the last part showing the code from line 2002 is also supposed
to include the fact that for whatever reason "barnyard2_conf ->
class_file" variable has NULL value so "SignatureResolveClassification"
method returns 1 and barnyard2 fails to start.

Hopefully this goes through... :-)

[Marco Belmonte]

... and he found �barnyard2_conf->class_file� variable has NULL value,
�SignatureResolveClassification� method returns 1 so our diapers get full.

[beenph]

Hi Marco,

Well thats a long one, thanks for all the info and excuse me if i top post.

1. No need to link by2 against pf_ring at all.


2. Even if you use sid-msg.mapv2 you need to include classification.config
to actually resolve literals to priority. Now i see that the file is
included in your
barnyard2.conf which leads me to think that i could be empty?
What is the look of the content of your classification.config file?


-elz

[Marco Belmonte]

On Thu, May 23, 2013 10:36 pm, beenph wrote:

> Well thats a long one, thanks for all the info and excuse me if i top
> post.

Thanks so much for answering :-)

> 1. No need to link by2 against pf_ring at all.

Good to know and we will recompile without linking pf_ring.

> 2. Even if you use sid-msg.mapv2 you need to include
> classification.config to actually resolve literals to priority. Now i see
> that the file is included in your barnyard2.conf which leads me to think
> that i could be empty? What is the look of the content of your
> classification.config file?

--- cut here ---

root@srvids01:/etc/snort# cat classification.config

# $Id: classification.config,v 1.4 2010-04-15 19:53:02 mwatchinski Exp $

config classification: not-suspicious,Not Suspicious Traffic,3
config classification: unknown,Unknown Traffic,3
config classification: bad-unknown,Potentially Bad Traffic, 2
config classification: attempted-recon,Attempted Information Leak,2
config classification: successful-recon-limited,Information Leak,2
config classification: successful-recon-largescale,Large Scale Information
Leak,2
config classification: attempted-dos,Attempted Denial of Service,2
config classification: successful-dos,Denial of Service,2
config classification: attempted-user,Attempted User Privilege Gain,1
config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1
config classification: successful-user,Successful User Privilege Gain,1
config classification: attempted-admin,Attempted Administrator Privilege
Gain,1
config classification: successful-admin,Successful Administrator Privilege
Gain,1
config classification: rpc-portmap-decode,Decode of an RPC Query,2
config classification: shellcode-detect,Executable Code was Detected,1
config classification: string-detect,A Suspicious String was Detected,3
config classification: suspicious-filename-detect,A Suspicious Filename
was Detected,2
config classification: suspicious-login,An Attempted Login Using a
Suspicious Username was Detected,2
config classification: system-call-detect,A System Call was Detected,2
config classification: tcp-connection,A TCP Connection was Detected,4
config classification: trojan-activity,A Network Trojan was Detected, 1
config classification: unusual-client-port-connection,A Client was Using
an Unusual Port,2
config classification: network-scan,Detection of a Network Scan,3
config classification: denial-of-service,Detection of a Denial of Service
Attack,2
config classification: non-standard-protocol,Detection of a Non-Standard
Protocol or Event,2
config classification: protocol-command-decode,Generic Protocol Command
Decode,3
config classification: web-application-activity,Access to a Potentially
Vulnerable Web Application,2
config classification: web-application-attack,Web Application Attack,1
config classification: misc-activity,Misc activity,3
config classification: misc-attack,Misc Attack,2
config classification: icmp-event,Generic ICMP event,3
config classification: inappropriate-content,Inappropriate Content was
Detected,1
config classification: policy-violation,Potential Corporate Privacy
Violation,1
config classification: default-login-attempt,Attempt to Login By a Default
Username and Password,2
config classification: sdf,Sensitive Data was Transmitted Across the
Network,2

--- cut here ---

I pulled the file up in Vim and didn't find any weird control characters
in it, etc. Let me know what we can provide to help you help us ;-)

Kind Regards,

- Marco

[beenph]

On Fri, May 24, 2013 at 5:50 PM, Marco Belmonte
<ma...@heavenlysanctuary.com> wrote:

Hi Marco,

>> 1. No need to link by2 against pf_ring at all.
>
> Good to know and we will recompile without linking pf_ring.
>

;)

>
> root@srvids01:/etc/snort# cat classification.config
>
Seem's legit.

>
> I pulled the file up in Vim and didn't find any weird control characters
> in it, etc. Let me know what we can provide to help you help us ;-)
>

Mabey this could help see whats occuring


Can you compile with --enable-debug and run barnyard2
BARNYARD2_DEBUG=0x00003000 <$PATH>/barnyard2 <arguments>

And send the output?

Mabey attached since i think it could be large.

Thanks in advance,
-elz

[Marco Belmonte]

On Fri, May 24, 2013 5:40 pm, beenph wrote:

> Can you compile with --enable-debug and run barnyard2
> BARNYARD2_DEBUG=0x00003000 <$PATH>/barnyard2 <arguments>

Hi Beenph,

Strangely, adding the --enable-debug option to my configure script and
then compiling results in errors:

My configure line:

./configure --enable-debug --enable-ipv6 --enable-mysql-ssl-support

--enable-gre --enable-mpls --with-mysql-includes="/usr/include/mysql"
--with-mysql-libraries="/usr/lib/x86_64-linux-gnu"

When I run make I get this:

--- cut here ---

root@srvids01:/usr/local/src/barnyard2# make -j8
make all-recursive
make[1]: Entering directory `/usr/local/src/barnyard2'
Making all in src
make[2]: Entering directory `/usr/local/src/barnyard2/src'
Making all in sfutil
make[3]: Entering directory `/usr/local/src/barnyard2/src/sfutil'
colorgcc -DHAVE_CONFIG_H -I. -I../.. -I.. -DSUP_IP6 -DGRE -DMPLS -DDEBUG
-I/usr/include/mysql -DENABLE_MYSQL -DMYSQL_SSL_SUPPORT -march=native -O0
-pipe -fomit-frame-pointer -g -fno-strict-aliasing -Wall -c getopt_long.c
.
.
.
<snip>
.
.
.
colorgcc -DHAVE_CONFIG_H -I. -I../.. -I.. -I ../sfutil -DSUP_IP6 -DGRE
-DMPLS -DDEBUG -I/usr/include/mysql -DENABLE_MYSQL -DMYSQL_SSL_SUPPORT
-march=native -O0 -pipe -fomit-frame-pointer -g -fno-strict-aliasing -Wall
-c spo_alert_test.c
spo_alert_fwsam.c: In function ïŋ―inettoaïŋ―:
spo_alert_fwsam.c:906:5: error: incompatible type for argument 1 of
ïŋ―sfip_to_strïŋ―
In file included from ../sfutil/sf_ipvar.h:35:0,
from ../barnyard2.h:49,
from spo_alert_fwsam.c:91:
../sfutil/sf_ip.h:426:7: note: expected ïŋ―const struct sfip_t *ïŋ― but
argument is of type ïŋ―struct in_addrïŋ―
spo_alert_fwsam.c: In function ïŋ―AlertFWsamïŋ―:
spo_alert_fwsam.c:979:18: warning: variable ïŋ―cnïŋ― set but not used
[-Wunused-but-set-variable]
spo_alert_fwsam.c:971:27: warning: variable ïŋ―lastbspïŋ― set but not used
[-Wunused-but-set-variable]
make[3]: *** [spo_alert_fwsam.o] Error 1
make[3]: *** Waiting for unfinished jobs....
spo_alert_cef.c: In function ïŋ―AlertCEFïŋ―:
spo_alert_cef.c:500:15: warning: variable ïŋ―cnïŋ― set but not used
[-Wunused-but-set-variable]
make[3]: Leaving directory `/usr/local/src/barnyard2/src/output-plugins'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/barnyard2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/barnyard2'
make: *** [all] Error 2

--- cut here ---

I am compiling on Debian Jessie (testing). Is it possible I need to
downgrade some libraries? It compiles fine without the debug option...

Let me know what information would be helpful and I'll do my best to
provide it. :-)

> Maybe attached since i think it could be large.

Will make sure I do that for sure.

- Marco

[beenph]

Remove --enable-ipv6 from configure flags.

> spo_alert_fwsam.c: In function ‘inettoa’:

> spo_alert_fwsam.c:906:5: error: incompatible type for argument 1 of

> ‘sfip_to_str’

> In file included from ../sfutil/sf_ipvar.h:35:0,
> from ../barnyard2.h:49,
> from spo_alert_fwsam.c:91:

> ../sfutil/sf_ip.h:426:7: note: expected ‘const struct sfip_t *’ but
> argument is of type ‘struct in_addr’
> spo_alert_fwsam.c: In function ‘AlertFWsam’:
> spo_alert_fwsam.c:979:18: warning: variable ‘cn’ set but not used
> [-Wunused-but-set-variable]
> spo_alert_fwsam.c:971:27: warning: variable ‘lastbsp’ set but not used

> [-Wunused-but-set-variable]
> make[3]: *** [spo_alert_fwsam.o] Error 1
> make[3]: *** Waiting for unfinished jobs....

> spo_alert_cef.c: In function ‘AlertCEF’:
> spo_alert_cef.c:500:15: warning: variable ‘cn’ set but not used

[Marco Belmonte]

That did it :-)

Attached is the requested output - let me know if you need anything
else. Also, it was good for me to do that - I will remember it in the
event I ever have Barnyard issues in the future.

- Marco

[beenph]

On Sat, May 25, 2013 at 5:30 AM, Marco Belmonte
<ma...@heavenlysanctuary.com> wrote:
> That did it :-)
>



> Attached is the requested output - let me know if you need anything else.
> Also, it was good for me to do that - I will remember it in the event I ever
> have Barnyard issues in the future.
>

The debug flag can change depending on which types of messages you
want look at src/debug.h for more info.


Now i think ive fixed it it was mainly a early free of the pathname of
the classification file after reading it that was
making the function SignatureResolveClassification() to bail early.

Can you download the from here, build it wand retry the binary and
confirm its working?

https://github.com/binf/barnyard2/tree/bug-fix-release


Cheers,
-elz

[Marco Belmonte]

On 05/25/2013 07:39 AM, beenph wrote:
> The debug flag can change depending on which types of messages you
> want look at src/debug.h for more info.

Ah, thanks - I'll make sure I "vim/less/more/pico/nano/cat debug.h" for
various goodies.

> Now i think ive fixed it it was mainly a early free of the pathname of
> the classification file after reading it that was
> making the function SignatureResolveClassification() to bail early.
>
> Can you download the from here, build it wand retry the binary and
> confirm its working?
>
> https://github.com/binf/barnyard2/tree/bug-fix-release

Absolutely. I will do this in the next 24 and post back results.

- Marco

[Marco Belmonte]

Hi Beenph,

I compiled the "bug-fix-release" branch from the git repo you linked and
it compiled and looked like it was going to run (instead of dying at
startup) but then this:

--- cut here ---

*** Error in `/usr/local/bin/barnyard2': munmap_chunk(): invalid
pointer: 0x000000000137c310 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7aac6)[0x7f6304ac7ac6]
/usr/local/bin/barnyard2[0x403f11]
/usr/local/bin/barnyard2[0x404235]
/usr/local/bin/barnyard2[0x419277]
/usr/local/bin/barnyard2[0x42aca6]
/usr/local/bin/barnyard2[0x430d1c]
/usr/local/bin/barnyard2[0x430e76]
/usr/local/bin/barnyard2[0x43122e]
/usr/local/bin/barnyard2[0x42bfb8]
/usr/local/bin/barnyard2[0x415c78]
/usr/local/bin/barnyard2[0x405606]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f6304a6ea55]
/usr/local/bin/barnyard2[0x40325d]
======= Memory map: ========
00400000-0044a000 r-xp 00000000 08:11 2359303
/usr/local/bin/barnyard2
0064a000-0064b000 rw-p 0004a000 08:11 2359303
/usr/local/bin/barnyard2
0064b000-00681000 rw-p 00000000 00:00 0
01367000-018fd000 rw-p 00000000 00:00 0
[heap]
7f62fc000000-7f62fc021000 rw-p 00000000 00:00 0
7f62fc021000-7f6300000000 ---p 00000000 00:00 0
7f63030dc000-7f63030ef000 r-xp 00000000 08:02 3805067
/lib/x86_64-linux-gnu/libresolv-2.17.so
7f63030ef000-7f63032ef000 ---p 00013000 08:02 3805067
/lib/x86_64-linux-gnu/libresolv-2.17.so
7f63032ef000-7f63032f0000 r--p 00013000 08:02 3805067
/lib/x86_64-linux-gnu/libresolv-2.17.so
7f63032f0000-7f63032f1000 rw-p 00014000 08:02 3805067
/lib/x86_64-linux-gnu/libresolv-2.17.so
7f63032f1000-7f63032f3000 rw-p 00000000 00:00 0
7f63032f3000-7f63032f8000 r-xp 00000000 08:02 3805060
/lib/x86_64-linux-gnu/libnss_dns-2.17.so
7f63032f8000-7f63034f7000 ---p 00005000 08:02 3805060
/lib/x86_64-linux-gnu/libnss_dns-2.17.so
7f63034f7000-7f63034f8000 r--p 00004000 08:02 3805060
/lib/x86_64-linux-gnu/libnss_dns-2.17.so
7f63034f8000-7f63034f9000 rw-p 00005000 08:02 3805060
/lib/x86_64-linux-gnu/libnss_dns-2.17.so
7f63034f9000-7f63034fa000 ---p 00000000 00:00 0
7f63034fa000-7f6303cfa000 rw-p 00000000 00:00 0
7f6303cfa000-7f6303d06000 r-xp 00000000 08:02 3805061
/lib/x86_64-linux-gnu/libnss_files-2.17.so
7f6303d06000-7f6303f05000 ---p 0000c000 08:02 3805061
/lib/x86_64-linux-gnu/libnss_files-2.17.so
7f6303f05000-7f6303f06000 r--p 0000b000 08:02 3805061
/lib/x86_64-linux-gnu/libnss_files-2.17.so
7f6303f06000-7f6303f07000 rw-p 0000c000 08:02 3805061
/lib/x86_64-linux-gnu/libnss_files-2.17.so
7f6303f07000-7f6303f1c000 r-xp 00000000 08:02 3801123
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f6303f1c000-7f630411c000 ---p 00015000 08:02 3801123
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f630411c000-7f630411d000 rw-p 00015000 08:02 3801123
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f630411d000-7f6304207000 r-xp 00000000 08:02 2621514
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18
7f6304207000-7f6304406000 ---p 000ea000 08:02 2621514
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18
7f6304406000-7f630440e000 r--p 000e9000 08:02 2621514
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18
7f630440e000-7f6304410000 rw-p 000f1000 08:02 2621514
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18
7f6304410000-7f6304425000 rw-p 00000000 00:00 0
7f6304425000-7f630442c000 r-xp 00000000 08:02 3805068
/lib/x86_64-linux-gnu/librt-2.17.so
7f630442c000-7f630462b000 ---p 00007000 08:02 3805068
/lib/x86_64-linux-gnu/librt-2.17.so
7f630462b000-7f630462c000 r--p 00006000 08:02 3805068
/lib/x86_64-linux-gnu/librt-2.17.so
7f630462c000-7f630462d000 rw-p 00007000 08:02 3805068
/lib/x86_64-linux-gnu/librt-2.17.so
7f630462d000-7f6304630000 r-xp 00000000 08:02 3801564
/lib/x86_64-linux-gnu/libdl-2.17.so
7f6304630000-7f630482f000 ---p 00003000 08:02 3801564
/lib/x86_64-linux-gnu/libdl-2.17.so
7f630482f000-7f6304830000 r--p 00002000 08:02 3801564
/lib/x86_64-linux-gnu/libdl-2.17.so
7f6304830000-7f6304831000 rw-p 00003000 08:02 3801564
/lib/x86_64-linux-gnu/libdl-2.17.so
7f6304831000-7f6304848000 r-xp 00000000 08:02 3801556
/lib/x86_64-linux-gnu/libpthread-2.17.so
7f6304848000-7f6304a47000 ---p 00017000 08:02 3801556
/lib/x86_64-linux-gnu/libpthread-2.17.so
7f6304a47000-7f6304a48000 r--p 00016000 08:02 3801556
/lib/x86_64-linux-gnu/libpthread-2.17.so
7f6304a48000-7f6304a49000 rw-p 00017000 08:02 3801556
/lib/x86_64-linux-gnu/libpthread-2.17.so
7f6304a49000-7f6304a4d000 rw-p 00000000 00:00 0
7f6304a4d000-7f6304bf1000 r-xp 00000000 08:02 3801560
/lib/x86_64-linux-gnu/libc-2.17.so
7f6304bf1000-7f6304df0000 ---p 001a4000 08:02 3801560
/lib/x86_64-linux-gnu/libc-2.17.so
7f6304df0000-7f6304df4000 r--p 001a3000 08:02 3801560
/lib/x86_64-linux-gnu/libc-2.17.so
7f6304df4000-7f6304df6000 rw-p 001a7000 08:02 3801560
/lib/x86_64-linux-gnu/libc-2.17.so
7f6304df6000-7f6304dfa000 rw-p 00000000 00:00 0
7f6304dfa000-7f6304ef7000 r-xp 00000000 08:02 3801565
/lib/x86_64-linux-gnu/libm-2.17.so
7f6304ef7000-7f63050f6000 ---p 000fd000 08:02 3801565
/lib/x86_64-linux-gnu/libm-2.17.so
7f63050f6000-7f63050f7000 r--p 000fc000 08:02 3801565
/lib/x86_64-linux-gnu/libm-2.17.so
7f63050f7000-7f63050f8000 rw-p 000fd000 08:02 3801565
/lib/x86_64-linux-gnu/libm-2.17.so
7f63050f8000-7f630510d000 r-xp 00000000 08:02 3801567
/lib/x86_64-linux-gnu/libnsl-2.17.so
7f630510d000-7f630530c000 ---p 00015000 08:02 3801567
/lib/x86_64-linux-gnu/libnsl-2.17.so
7f630530c000-7f630530d000 r--p 00014000 08:02 3801567
/lib/x86_64-linux-gnu/libnsl-2.17.so
7f630530d000-7f630530e000 rw-p 00015000 08:02 3801567
/lib/x86_64-linux-gnu/libnsl-2.17.so
7f630530e000-7f6305310000 rw-p 00000000 00:00 0
7f6305310000-7f6305363000 r-xp 00000000 08:11 3670125
/usr/local/lib/libpcap.so.1.1.1
7f6305363000-7f6305563000 ---p 00053000 08:11 3670125
/usr/local/lib/libpcap.so.1.1.1
7f6305563000-7f6305566000 rw-p 00053000 08:11 3670125
/usr/local/lib/libpcap.so.1.1.1
7f6305566000-7f630557d000 r-xp 00000000 08:02 3801184
/lib/x86_64-linux-gnu/libz.so.1.2.8
7f630557d000-7f630577c000 ---p 00017000 08:02 3801184
/lib/x86_64-linux-gnu/libz.so.1.2.8
7f630577c000-7f630577d000 r--p 00016000 08:02 3801184
/lib/x86_64-linux-gnu/libz.so.1.2.8
7f630577d000-7f630577e000 rw-p 00017000 08:02 3801184
/lib/x86_64-linux-gnu/libz.so.1.2.8
7f630577e000-7f6305a3d000 r-xp 00000000 08:02 2624742
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0
7f6305a3d000-7f6305c3c000 ---p 002bf000 08:02 2624742
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0
7f6305c3c000-7f6305c42000 r--p 002be000 08:02 2624742
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0
7f6305c42000-7f6305cc0000 rw-p 002c4000 08:02 2624742
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0
7f6305cc0000-7f6305cc5000 rw-p 00000000 00:00 0
7f6305cc5000-7f6305ce6000 r-xp 00000000 08:02 3801557
/lib/x86_64-linux-gnu/ld-2.17.so
7f6305ecf000-7f6305ed7000 rw-p 00000000 00:00 0
7f6305ee3000-7f6305ee6000 rw-p 00000000 00:00 0
7f6305ee6000-7f6305ee7000 r--p 00021000 08:02 3801557
/lib/x86_64-linux-gnu/ld-2.17.so
7f6305ee7000-7f6305ee8000 rw-p 00022000 08:02 3801557
/lib/x86_64-linux-gnu/ld-2.17.so
7f6305ee8000-7f6305ee9000 rw-p 00000000 00:00 0
7fff25583000-7fff255a4000 rw-p 00000000 00:00 0
[stack]
7fff255ff000-7fff25600000 r-xp 00000000 00:00 0
[vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]

--- cut here ---

Then I realized I hadn't emptied the "sig_reference" table so I did a
"truncate sig_reference;" and restarted... The exact same thing happens
as above except this time one barnyard2 process continues to run. The
other 5 processes spit out the above dump and I can see in
/var/log/daemon.log the following for each process:

--- cut here ---

May 26 16:23:54 srvids01 barnyard2[2092]: FATAL ERROR: database
mysql_error: Duplicate entry '102351-2' for key
'PRIMARY'#012#011SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq)
VALUES ('14276','102351','2');]

--- cut here ---

I recompiled with "--enable-debug" and did this (which I got from your
debug.h comments):

BARNYARD2_DEBUG=0x00000001 /usr/local/bin/barnyard2
--disable-alert-on-each-packet-in-stream -n -r in2 -d

/usr/local/log/snort/in2 -f snort.u2 -X /tmp/snort/in2/barnyard2.pid -i

in2 -w /usr/local/log/snort/in2/in2.waldo -a
/usr/local/log/snort/in2/processed -c /etc/snort/barnyard2-in2.conf

There was one instance of barnyard2 running as a daemon already so when
I ran this to get the debug information I obviously omitted the "-D" and
to my surprise it started up and ran but once I hit CTRL-C it barfed
with the same output as posted above:

--- cut here ---

root@srvids01:/etc/snort/scripts# BARNYARD2_DEBUG=0x00000001
/usr/local/bin/barnyard2 --disable-alert-on-each-packet-in-stream -n -r
in2 -d /usr/local/log/snort/in2 -f snort.u2 -X
/tmp/snort/in2/barnyard2.pid -i in2 -w
/usr/local/log/snort/in2/in2.waldo -a /usr/local/log/snort/in2/processed
-c /etc/snort/barnyard2-in2.conf

barnyard2.c:574: Parsing command line...
barnyard2.c:644: Processing cmd line switch:

barnyard2.c:644: Processing cmd line switch: n
barnyard2.c:644: Processing cmd line switch: r
barnyard2.c:644: Processing cmd line switch: d
barnyard2.c:644: Processing cmd line switch: f
barnyard2.c:644: Processing cmd line switch: X
parser.c:1765: Verbose packet bytecode dumps enabled
barnyard2.c:644: Processing cmd line switch: i
barnyard2.c:644: Processing cmd line switch: w
barnyard2.c:644: Processing cmd line switch: a
barnyard2.c:644: Processing cmd line switch: c
barnyard2.c:1680: Config file = /etc/snort/barnyard2-in2.conf, config
dir = /etc/snort/

Running in Continuous mode

--== Initializing Barnyard2 ==--
Initializing Input Plugins!

spi_unified2.c:97: Input plugin: Unified2 is setup...
Initializing Output Plugins!
spo_alert_cef.c:105: Output plugin: Alert-CEF is setup...
spo_alert_syslog.c:106: Output plugin: Alert-Syslog is setup...
spo_log_tcpdump.c:139: Output plugin: Log-Tcpdump is setup...
spo_database.c:292: database(debug): database plugin is registered...
spo_alert_fast.c:117: Output plugin: AlertFast is setup...
spo_alert_full.c:110: Output plugin: AlertFull is setup...
DEBUG => [Alert_FWsam](AlertFWsamSetup) Output plugin is plugged in...
spo_alert_unixsock.c:107: Output plugin: AlertUnixSock is setup...
spo_alert_csv.c:121: Output plugin: alert_csv is setup...
spo_alert_test.c:128: Output plugin: AlertTest is setup...
Parsing config file "/etc/snort/barnyard2-in2.conf"
parser.c:1756: Payload dump set
parser.c:2180: Verbose Flag active

+[ Signature Suppress list ]+
----------------------------
+[No entry in Signature Suppress List]+
----------------------------
+[ Signature Suppress list ]+

Barnyard2 spooler: Event cache size set to [4096]

Log directory = /var/log/barnyard2
spi_unified2.c:105: Linking UnifiedLog functions to call lists...
INFO database: Defaulting Reconnect sleep time to 5 second
Checking PID path...
PID path stat checked out ok, PID path set to /var/run/
Writing PID "11272" to file "/var/run//barnyard2_in2in2.pid"
Node unique name is: srvids01:in2

database: compiled support for (mysql)
database: configured to use mysql
database: schema version = 107
database: host = srvids02.riaenviaca.com
database: database name = snorby
database: sensor name = srvids01:in2
database: sensor id = 7
database: sensor cid = 1314
database: data encoding = hex
database: detail level = full
database: ignore_bpf = no
database: using the "log" facility
-------------------------------------------------
Keyword | Input @
-------------------------------------------------
unified2 : init() = 0x44a3ad
unified2 : - readRecordHeader() = 0x44a420
unified2 : - readRecord() = 0x44a5f8
-------------------------------------------------

-------------------------------------------------
Keyword | Output @
-------------------------------------------------
alert_cef : 0x42c837
alert_syslog : 0x433526
log_tcpdump : 0x4361f1
database : 0x43d638
alert_fast : 0x42e85d
alert_full : 0x42f4fe
alert_fwsam : 0x42fd20
alert_unixsock: 0x434b56
alert_csv : 0x42d36a
log_null : 0x4360de
log_ascii : 0x4354b2
alert_test : 0x434376
sguil : 0x437020
alert_syslog_full: 0x43825a
log_syslog_full: 0x438239
-------------------------------------------------


--== Initialization Complete ==--

______ -*> Barnyard2 <*-
/ ,,_ \ Version 2.1.13 (Build 327) DEBUG
|o" )~| By Ian Firns (SecurixLive): http://www.securixlive.com/
+ '''' + (C) Copyright 2008-2013 Ian Firns <fir...@securixlive.com>

Using waldo file '/usr/local/log/snort/in2/in2.waldo':
spool directory = /usr/local/log/snort/in2
spool filebase = snort.u2
time_stamp = 1369474309
record_idx = 8
Processing new records only.
Skipping file: /usr/local/log/snort/in2/snort.u2.1369474309
Skipping file: /usr/local/log/snort/in2/snort.u2.1369474310
Opened spool file '/usr/local/log/snort/in2/snort.u2.1369608621'
Skipped 0 old records
Waiting for new data <------------------- DIDN'T CRASH :-)
^C*** Caught Int-Signal
Barnyard2 exiting
database: Closing connection to database "snorby"
===============================================================================
Record Totals:
Records: 0
Events: 0 (0.000%)
Packets: 0 (0.000%)
Unknown: 0 (0.000%)
Suppressed: 0 (0.000%)
===============================================================================
Packet breakdown by protocol (includes rebuilt packets):
ETH: 0 (0.000%)
ETHdisc: 0 (0.000%)
VLAN: 0 (0.000%)
IPV6: 0 (0.000%)
IP6 EXT: 0 (0.000%)
IP6opts: 0 (0.000%)
IP6disc: 0 (0.000%)
IP4: 0 (0.000%)
IP4disc: 0 (0.000%)
TCP 6: 0 (0.000%)
UDP 6: 0 (0.000%)
ICMP6: 0 (0.000%)
ICMP-IP: 0 (0.000%)
TCP: 0 (0.000%)
UDP: 0 (0.000%)
ICMP: 0 (0.000%)
TCPdisc: 0 (0.000%)
UDPdisc: 0 (0.000%)
ICMPdis: 0 (0.000%)
FRAG: 0 (0.000%)
FRAG 6: 0 (0.000%)
ARP: 0 (0.000%)
EAPOL: 0 (0.000%)
ETHLOOP: 0 (0.000%)
IPX: 0 (0.000%)
IPv4/IPv4: 0 (0.000%)
IPv4/IPv6: 0 (0.000%)
IPv6/IPv4: 0 (0.000%)
IPv6/IPv6: 0 (0.000%)
GRE: 0 (0.000%)
GRE ETH: 0 (0.000%)
GRE VLAN: 0 (0.000%)
GRE IPv4: 0 (0.000%)
GRE IPv6: 0 (0.000%)
GRE IP6 E: 0 (0.000%)
GRE PPTP: 0 (0.000%)
GRE ARP: 0 (0.000%)
GRE IPX: 0 (0.000%)
GRE LOOP: 0 (0.000%)
MPLS: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
InvChkSum: 0 (0.000%)
S5 G 1: 0 (0.000%)
S5 G 2: 0 (0.000%)
Total: 0
===============================================================================
Closing spool file '/usr/local/log/snort/in2/snort.u2.1369608621'. Read
0 records
*** Error in `/usr/local/bin/barnyard2': munmap_chunk(): invalid
pointer: 0x0000000001e6afc0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7aac6)[0x7f7f86b30ac6]
/usr/local/bin/barnyard2[0x406f96]
/usr/local/bin/barnyard2[0x405d5e]
/usr/local/bin/barnyard2[0x405475]
/usr/local/bin/barnyard2[0x404f7c]
/usr/local/bin/barnyard2[0x40577d]
/usr/local/bin/barnyard2[0x4039be]
/usr/local/bin/barnyard2[0x4037bc]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f7f86ad7a55]
/usr/local/bin/barnyard2[0x4035e9]
======= Memory map: ========
00400000-00469000 r-xp 00000000 08:11 2363725
/usr/local/bin/barnyard2
00668000-0066a000 rw-p 00068000 08:11 2363725
/usr/local/bin/barnyard2
0066a000-0069f000 rw-p 00000000 00:00 0
01e3c000-023cc000 rw-p 00000000 00:00 0
[heap]
7f7f80000000-7f7f80021000 rw-p 00000000 00:00 0
7f7f80021000-7f7f84000000 ---p 00000000 00:00 0
7f7f85145000-7f7f85158000 r-xp 00000000 08:02 3805067
/lib/x86_64-linux-gnu/libresolv-2.17.so
7f7f85158000-7f7f85358000 ---p 00013000 08:02 3805067
/lib/x86_64-linux-gnu/libresolv-2.17.so
7f7f85358000-7f7f85359000 r--p 00013000 08:02 3805067
/lib/x86_64-linux-gnu/libresolv-2.17.so
7f7f85359000-7f7f8535a000 rw-p 00014000 08:02 3805067
/lib/x86_64-linux-gnu/libresolv-2.17.so
7f7f8535a000-7f7f8535c000 rw-p 00000000 00:00 0
7f7f8535c000-7f7f85361000 r-xp 00000000 08:02 3805060
/lib/x86_64-linux-gnu/libnss_dns-2.17.so
7f7f85361000-7f7f85560000 ---p 00005000 08:02 3805060
/lib/x86_64-linux-gnu/libnss_dns-2.17.so
7f7f85560000-7f7f85561000 r--p 00004000 08:02 3805060
/lib/x86_64-linux-gnu/libnss_dns-2.17.so
7f7f85561000-7f7f85562000 rw-p 00005000 08:02 3805060
/lib/x86_64-linux-gnu/libnss_dns-2.17.so
7f7f85562000-7f7f85563000 ---p 00000000 00:00 0
7f7f85563000-7f7f85d63000 rw-p 00000000 00:00 0
7f7f85d63000-7f7f85d6f000 r-xp 00000000 08:02 3805061
/lib/x86_64-linux-gnu/libnss_files-2.17.so
7f7f85d6f000-7f7f85f6e000 ---p 0000c000 08:02 3805061
/lib/x86_64-linux-gnu/libnss_files-2.17.so
7f7f85f6e000-7f7f85f6f000 r--p 0000b000 08:02 3805061
/lib/x86_64-linux-gnu/libnss_files-2.17.so
7f7f85f6f000-7f7f85f70000 rw-p 0000c000 08:02 3805061
/lib/x86_64-linux-gnu/libnss_files-2.17.so
7f7f85f70000-7f7f85f85000 r-xp 00000000 08:02 3801123
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f7f85f85000-7f7f86185000 ---p 00015000 08:02 3801123
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f7f86185000-7f7f86186000 rw-p 00015000 08:02 3801123
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f7f86186000-7f7f86270000 r-xp 00000000 08:02 2621514
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18
7f7f86270000-7f7f8646f000 ---p 000ea000 08:02 2621514
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18
7f7f8646f000-7f7f86477000 r--p 000e9000 08:02 2621514
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18
7f7f86477000-7f7f86479000 rw-p 000f1000 08:02 2621514
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18
7f7f86479000-7f7f8648e000 rw-p 00000000 00:00 0
7f7f8648e000-7f7f86495000 r-xp 00000000 08:02 3805068
/lib/x86_64-linux-gnu/librt-2.17.so
7f7f86495000-7f7f86694000 ---p 00007000 08:02 3805068
/lib/x86_64-linux-gnu/librt-2.17.so
7f7f86694000-7f7f86695000 r--p 00006000 08:02 3805068
/lib/x86_64-linux-gnu/librt-2.17.so
7f7f86695000-7f7f86696000 rw-p 00007000 08:02 3805068
/lib/x86_64-linux-gnu/librt-2.17.so
7f7f86696000-7f7f86699000 r-xp 00000000 08:02 3801564
/lib/x86_64-linux-gnu/libdl-2.17.so
7f7f86699000-7f7f86898000 ---p 00003000 08:02 3801564
/lib/x86_64-linux-gnu/libdl-2.17.so
7f7f86898000-7f7f86899000 r--p 00002000 08:02 3801564
/lib/x86_64-linux-gnu/libdl-2.17.so
7f7f86899000-7f7f8689a000 rw-p 00003000 08:02 3801564
/lib/x86_64-linux-gnu/libdl-2.17.so
7f7f8689a000-7f7f868b1000 r-xp 00000000 08:02 3801556
/lib/x86_64-linux-gnu/libpthread-2.17.so
7f7f868b1000-7f7f86ab0000 ---p 00017000 08:02 3801556
/lib/x86_64-linux-gnu/libpthread-2.17.so
7f7f86ab0000-7f7f86ab1000 r--p 00016000 08:02 3801556
/lib/x86_64-linux-gnu/libpthread-2.17.so
7f7f86ab1000-7f7f86ab2000 rw-p 00017000 08:02 3801556
/lib/x86_64-linux-gnu/libpthread-2.17.so
7f7f86ab2000-7f7f86ab6000 rw-p 00000000 00:00 0
7f7f86ab6000-7f7f86c5a000 r-xp 00000000 08:02 3801560
/lib/x86_64-linux-gnu/libc-2.17.so
7f7f86c5a000-7f7f86e59000 ---p 001a4000 08:02 3801560
/lib/x86_64-linux-gnu/libc-2.17.soAborted

--- cut here ---

Let me know what else I can provide?

:-)

- Marco

[Marco Belmonte]

You know. I think this partly has to do with the way I'm starting
barnyard2 up. I'm not saying the way barnyard2 dumps is related - but
certainly the errors with populated the sig_reference table has to do
with me trying to start all barnyard2 processes up at the same time. I
think I should wait for each one to start and finish initialization and
run them sequentially. Then I probably should make a second startup
script which uses the new option to skip the population of the reference
table and only worry about sequential startup when a new rule set is
released - does this make sense?

[Marco Belmonte]

Beenph,

I deleted all unified2 log files, removed all waldo files, truncated the
sig_reference table and started each barnyard2 process up manually and
waited until the signatures were pre-populated before I tried to run the
next instance and now I have 6 successful barnyard2 daemons running in
daemon mode.

I will make sure that is the standard method I use in the future.

[Marco Belmonte]

Beenph,

Everything is working now - thanks so much for your help and guidance!

Kind Regards,

- Marco

[beenph]

Hi marco,

I just pushed a new version of the same fix (with an other unrelated fix).

Actually yes the warning message you where getting from that database
was because you probably didin't cleared the sig_reference before
upgrading.

But once this is done you can technically run concurrent process
without and issue.

The bug crash was comming from the imcomplete patch job i had done
which would get trigerred when the process was exiting and not before,
thus since other processes where crashing
and one was running you observed this only is specific situation.

I would encourage if you can to re-download from the same branch and
start your process buck-wild even re-clear the sig_reference table if
you want and report on how it goes, everything should go smoothly.

Because i currently assume that if you stop some or all your
daemons,they will crash. (on exit) not while processing stuff or on
startup, since they will try to free some memory that has already been
freed.)


As for your other question concerning startup procedure it really
depend on if the UI you are using uses the sig_reference table or not.
If it doses not then you could just use the database option
disable_signature_reference_table . This will greatly improve your
statup time since
this table has alot of entries and the method used to cache it and
populate it is not the most performant there is.

If you have further question,issues,problems.
Do not hesitate.

Cheers,
-elz

[Marco Belmonte]

On 05/26/2013 09:22 PM, beenph wrote:
> I would encourage if you can to re-download from the same branch and
> start your process buck-wild even re-clear the sig_reference table if
> you want and report on how it goes, everything should go smoothly.
>
> Because i currently assume that if you stop some or all your
> daemons,they will crash. (on exit) not while processing stuff or on
> startup, since they will try to free some memory that has already been
> freed.)

I will fetch the latest update via git and recompile as suggested. Thank
you sir :-)

> As for your other question concerning startup procedure it really
> depend on if the UI you are using uses the sig_reference table or not.
> If it doses not then you could just use the database option
> disable_signature_reference_table . This will greatly improve your
> statup time since
> this table has alot of entries and the method used to cache it and
> populate it is not the most performant there is.

How embarrassing! I never even thought to ask the question "is this
table even necessary?" - so now that you brought it up - I believe you
are right - we don't need it. lol! I will add the new config option to
our barnyard2 configuration file(s).

> If you have further question,issues,problems.
> Do not hesitate.
>

Once again, thanks for everything :-)

- Marco