Re: Barnyard2 reports database insert errors

[beenph <beenph () gmail com>]

On Fri, Nov 1, 2013 at 11:11 PM, Dave Corsello
<snort-users () wintertreemedia com> wrote:
> I wonder if this problem could be related to the fact that this is all
> happening within ESXi.  My server has plenty of processing power and memory.
>
> I also wonder if it could be related to my version of Linux or the the
> versions of prerequisite software?  I'm running Ubuntu 10.04.3.  Upgrading
> is not an option.

I really mutch doubt that the two above options are related to what is
happening.


> Here are my answers to your questions:
>
> 1.  I'm using barnyard2 ver. 2.1.13 build 327.


> 2.  There's only one barnyard2 process and only one snort process running.
> The timestamp in the error message is the same as the timestamp of the
> corresponding record in the database.To me, this means that either: 1)
> there's just one successful insert, and barnyard2 isn't getting notified
> that the insert was successful; or 2) the event is triggering multiple times
> during the span of one second and the cid isn't incrementing. But 3 days
> ago, the very same signature triggered three times within the span of one
> second, and the cid incremented to allow insertion of all 3 alerts.

Timestamp is not necessarly important (while yes it can allow you to correlate)
You can have more than on event with the same timestamp, thus its not
a definitive
identifiant, especialy at the schema level. And cid is incremented
everytime an event is logged.


> By elimination, I think the possibilities are that either: 1) MySQL is
> intermittently not sending back a status; 2) barnyard2 is intermittently not
> processing the MySQL status that it receives; or 3) sometimes the status
> message gets lost between the MySQL box and the Snort box.  Number 3 might
> be supported by the fact that the NIC on my MySQL box shows in the
> neighborhood of 500 RX-ERR packets for every 3 million RX-OK packets daily.
> My Snort box shows consistently 0 RX-ERR and 0 TX-ERR.  But it would seem to
> me that RX-ERRs on the MySQL box would more likely result in botched
> inserts, not in status messages failing to transmit, right?  Unless the
> packets that are failing are ones that would indicate where MySQL should
> send a status message...  I wonder if this would cause MySQL to throw errors
> that appear in a log...  Nope, the MySQL error logs are empty.  Again, the
> RX-ERRs could be related to something peculiar within the overall
> environment.  I'll look into that when I have time.

I do not even understand that you mean by "status" at the mysql level.

What i think is that you could have had a network outtage link betwen
the by2 vm and the mysql vm
and that as soon as the connection was brought back up, operation
resumed to normal but you got
the error message logged.

Anyhow if i look at the original err message you posted there was
probably more data thant just this
<SNIP>
Nov 1 10:25:14 snort2 barnyard2[XXXXX]: [Database()]: Insertion of Query
[INSERT INTO event (sid,cid,signature,timestamp) VALUES (X, XXXXXX,
XXXXXX, '2013-11-01 10:25:09');] failed
</SNIP>

You probably got the full stack of the event logged to syslog like it
should be outputting.


> 3.  Here's the result of the query that you suggested:
>
> +-------------------+--------+
> | table_name        | engine |
> +-------------------+--------+
> | acid_ag           | MyISAM |
> | acid_ag_alert     | MyISAM |
> | acid_event        | MyISAM |
> | acid_ip_cache     | MyISAM |
> | agent_asset_names | InnoDB |
> | aggregated_events | NULL   |
> | asset_names       | InnoDB |
> | base_roles        | MyISAM |
> | base_users        | MyISAM |
> | caches            | InnoDB |
> | classifications   | InnoDB |
> | daily_caches      | InnoDB |
> | data              | InnoDB |
> | delayed_jobs      | InnoDB |
> | detail            | InnoDB |
> | encoding          | InnoDB |
> | event             | InnoDB |
> | events_with_join  | NULL   |
> | favorites         | InnoDB |
> | icmphdr           | InnoDB |
> | iphdr             | InnoDB |
> | lookups           | InnoDB |
> | notes             | InnoDB |
> | notifications     | InnoDB |
> | opt               | InnoDB |
> | reference         | InnoDB |
> | reference_system  | InnoDB |
> | schema            | InnoDB |
> | search            | InnoDB |
> | sensor            | InnoDB |
> | settings          | InnoDB |
> | severities        | InnoDB |
> | sig_class         | InnoDB |
> | sig_reference     | InnoDB |
> | signature         | InnoDB |
> | tcphdr            | InnoDB |
> | udphdr            | InnoDB |
> | users             | InnoDB |
> +-------------------+--------+

Seem's fine as long as your tables are native innodb tables and not
converted using ALTER TABLE.


-elz

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
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!