Snort Alert [gid:sid:revision] instead of signature name

[rew...@gmail.com]

Hi,

Definitely I'm doing something wrong, but after days of searching I can't find what. The only info I found is to have the gen-msg and sid-msg up to date.
The gen-msg.map and sid-msg.map are up to date, currently using pulledpork to update the rules.

First time when I start barnyard, the mysql database is getting populated with all the entries from gen-msg.map
I can see them with "SELECT *  FROM signature;"

Then the preprocessor alarms are coming up, barnyard2 is adding them in the database as Snort Alert [x.x.xxx]

barnyard2[25615]: INFO [dbProcessSignatureInformation()]: [Event: 89] with [gid: 129] [sid: 18] [rev: 1] [classification: 3] [priority: 2]    was not found in barnyard2 signature cache, this could lead to display inconsistency.

After this I'm grepping the gen-msg.map file for sig id 129 and manually changing it in the database.

Now if I look again in the database I have this signature twice, once added when barnyard started first time and once when the alarm came up for the first time.

+--------+--------------+-------------------------------------------------------+--------------+---------+---------+---------+--------------+
| sig_id | sig_class_id | sig_name                                                             | sig_priority | sig_rev | sig_sid | sig_gid | events_count |
+--------+--------------+-------------------------------------------------------+--------------+---------+---------+---------+--------------+
|    128 |            0 | stream5: Data sent on stream after TCP Reset received |            3 |       1 |      18 |     129 |            0 |
|    534 |            3 | stream5: Data sent on stream after TCP Reset received |            2 |       1 |      18 |     129 |          169 |
+--------+--------------+-------------------------------------------------------+--------------+---------+---------+---------+--------------+

The difference is the signature priority, but no idea where from these priorities are coming. Within gen-msg you have only the gid and sid of the signature. Is this the reason the alarm signature is added a second time?
Any idea what's happening here ?

Thanks
rew

[beenph]

On Mon, Aug 19, 2013 at 10:02 AM, <rew...@gmail.com> wrote:
> Hi,
>
Hi Rew,

see inline for comment/missing information.

> Definitely I'm doing something wrong, but after days of searching I can't
> find what. The only info I found is to have the gen-msg and sid-msg up to
> date.
> The gen-msg.map and sid-msg.map are up to date, currently using pulledpork
> to update the rules.
>
> First time when I start barnyard, the mysql database is getting populated
> with all the entries from gen-msg.map
> I can see them with "SELECT * FROM signature;"
>
> Then the preprocessor alarms are coming up, barnyard2 is adding them in the
> database as Snort Alert [x.x.xxx]

Which version of barnyard2 are you running?

>
> barnyard2[25615]: INFO [dbProcessSignatureInformation()]: [Event: 89] with
> [gid: 129] [sid: 18] [rev: 1] [classification: 3] [priority: 2] was not
> found in barnyard2 signature cache, this could lead to display
> inconsistency.
>

The message above from syslog is incomplete, could you paste the
complete message
this could help understand which code path is used and why.

> After this I'm grepping the gen-msg.map file for sig id 129 and manually
> changing it in the database.
>

How was the row looking before and after you changed it?

> Now if I look again in the database I have this signature twice, once added
> when barnyard started first time and once when the alarm came up for the
> first time.
>

But you mentionned above that you did issue a query to change
something in a row,
which row did you manually change and what was the query used?

> +--------+--------------+-------------------------------------------------------+--------------+---------+---------+---------+--------------+
> | sig_id | sig_class_id | sig_name
> | sig_priority | sig_rev | sig_sid | sig_gid | events_count |
> +--------+--------------+-------------------------------------------------------+--------------+---------+---------+---------+--------------+
> | 128 | 0 | stream5: Data sent on stream after TCP Reset
> received | 3 | 1 | 18 | 129 | 0 |
> | 534 | 3 | stream5: Data sent on stream after TCP Reset
> received | 2 | 1 | 18 | 129 | 169 |
> +--------+--------------+-------------------------------------------------------+--------------+---------+---------+---------+--------------+
>
> The difference is the signature priority, but no idea where from these
> priorities are coming. Within gen-msg you have only the gid and sid of the
> signature. Is this the reason the alarm signature is added a second time?
> Any idea what's happening here ?
>

Priority and classification, those are defined for preprocessor in
preprocessor.rule and in the preprocessor code it self.

-elz

[rew...@gmail.com]

Hey,

I'm using Barnyard2, Version 2.1.13-BETA (Build 325)

I will take a new example which came in today.

Here the message in the logs:
Aug 20 06:06:51 snort-sensor barnyard2[25615]: INFO [dbProcessSignatureInformation()]: [Event: 379] with [gid: 142] [sid: 2] [rev: 1] [classification: 26] [priority: 3]        was not found in barnyard2 signature cache, this could lead to display inconsistency.    To prevent this warning, make sure that your sid-msg.map and gen-msg.map file are up to date with the snort process logging to the spool file.   The new inserted signature will not have its information present in the sig_reference table.    Note that the message inserted in the signature table will be snort default message "Snort Alert [gid:sid:revision]"     You can allways update the message via a SQL query if you want it to be displayed correctly by your favorite interface

Querying the database:
mysql> SELECT * FROM signature where sig_name LIKE "Snort Alert%";
+--------+--------------+------------------------+--------------+---------+---------+---------+--------------+

| sig_id | sig_class_id | sig_name               | sig_priority | sig_rev | sig_sid | sig_gid | events_count |

+--------+--------------+------------------------+--------------+---------+---------+---------+--------------+
|    539 |            3 | Snort Alert [140:21:1] |            2 |       1 |      21 |     140 |            1 |
|    541 |           26 | Snort Alert [142:2:1]  |            3 |       1 |       2 |     142 |            1 |
+--------+--------------+------------------------+--------------+---------+---------+---------+--------------+
2 rows in set (0.01 sec)

Grepping gen-msg.map, looking for alert 142 2
142 || 2 || pop: Unknown POP3 response

Checking the database if signature already in there:
mysql> SELECT * FROM signature where sig_name LIKE "%pop: Unknown POP3 response%";
+--------+--------------+----------------------------+--------------+---------+---------+---------+--------------+

| sig_id | sig_class_id | sig_name                   | sig_priority | sig_rev | sig_sid | sig_gid | events_count |

+--------+--------------+----------------------------+--------------+---------+---------+---------+--------------+
|     18 |            0 | pop: Unknown POP3 response |            3 |       1 |       2 |     142 |            0 |
+--------+--------------+----------------------------+--------------+---------+---------+---------+--------------+
1 row in set (0.00 sec)

The signature is already there, nevertheless the alarm was added as a no name alarm. Updating the database:
mysql> UPDATE signature set sig_name="pop: Unknown POP3 response" WHERE sig_name like "Snort Alert %" AND sig_id="541";
Query OK, 1 row affected (0.04 sec)

This is my config file, the paths are correct, the files are readable by everyone:
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:   pig1
config interface:  eth1
config set_gid: 1000
config set_uid: 1000
config decode_data_link
config dump_payload
config umask: 066
input unified2
output database: log, mysql, user=snort password=xxx dbname=snort host=localhost

Any idea what may be wrong? Where should I look?

Thanks
rew

[rew...@gmail.com]

Looking back at what I wrote, I can see where the issue is. Classification doesn't match. All the rules barnyard wrote in the database, in the beginning, have classification 0, but the incoming alerts have numbers above 0.
No idea yet how barnyard puts up together the signature entries in the database...

[beenph]

On Tue, Aug 20, 2013 at 4:01 AM, <rew...@gmail.com> wrote:
> Looking back at what I wrote, I can see where the issue is. Classification
> doesn't match. All the rules barnyard wrote in the database, in the
> beginning, have classification 0, but the incoming alerts have numbers above
> 0.
> No idea yet how barnyard puts up together the signature entries in the
> database...
>
>

Rew,
I took some time to try and replicate (from initialization signature
to insertion of preprocessor event),
and was not able to reproduce the issue with current master.

You will find latest master found at https://github.com/firnsy/barnyard2.

The issue you are experiencing was a drawback of adding sid-msg.map v2 support
commit that fixes this was commited on may 13th.
"https://github.com/firnsy/barnyard2/commit/ba0ae7b71a67950505a16a7f046e29ffcad179bf"


Make sure that you have fixed all signture with the name "Snort Alert"
before running it
else the information will get updated (class and priority) with the
existing message and not
the proper message.

Sorry that you experienced some issue and i hope this will help you.

Cheers,
-elz

[rew...@gmail.com]

Hi,

I moved to "Version 2.1.13 (Build 327)" and I confirm the signature class is now
updated for existing signature entries. No more generic "Snort Alert" entries.

This was my first thought, to update barnyard, but hard to see there is a new
version out there. From the README file I was sure I'm running the latest one :)

Thanks a lot for your help. Problem solved.

cheers
rew