Suricata

It's not a known issue, which doesn't mean the issue can't be real :)

Suricata, like Snort, uses priorities from the classification.config. Can you double check if that part of your Suricata setup is configured correctly?

suricata config file :

classification-file: /etc/suricata/classification.config

cat /etc/suricata/classification.config

# $Id$
# classification.config taken from Snort 2.8.5.3. Snort is governed by the GPLv2
#
# The following includes information for prioritizing rules
#
# Each classification includes a shortname, a description, and a default
# priority for that classification.
#
# This allows alerts to be classified and prioritized.  You can specify
# what priority each classification has.  Any rule can override the default
# priority for that rule.
#
# Here are a few example rules:
#
#   alert TCP any any -> any 80 (msg: "EXPLOIT ntpdx overflow";
#       dsize: > 128; classtype:attempted-admin; priority:10;
#
#   alert TCP any any -> any 25 (msg:"SMTP expn root"; flags:A+; \
#             content:"expn root"; nocase; classtype:attempted-recon;)
#
# The first rule will set its type to "attempted-admin" and override
# the default priority for that type to 10.
#
# The second rule set its type to "attempted-recon" and set its
# priority to the default for that type.
#

#
# config classification:shortname,short description,priority
#

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

# NEW CLASSIFICATIONS
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: kickass-porn,SCORE! Get the lotion!,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

Snort :
include classification.config

cat /etc/snort/classification.conf

# $Id$
# The following includes information for prioritizing rules
# 
# Each classification includes a shortname, a description, and a default
# priority for that classification.
#
# This allows alerts to be classified and prioritized.  You can specify
# what priority each classification has.  Any rule can override the default
# priority for that rule.
#
# Here are a few example rules:
# 
#   alert TCP any any -> any 80 (msg: "EXPLOIT ntpdx overflow"; 
#       dsize: > 128; classtype:attempted-admin; priority:10;
#
#   alert TCP any any -> any 25 (msg:"SMTP expn root"; flags:A+; \
#             content:"expn root"; nocase; classtype:attempted-recon;)
#
# The first rule will set its type to "attempted-admin" and override 
# the default priority for that type to 10.
#
# The second rule set its type to "attempted-recon" and set its
# priority to the default for that type.
# 

#
# config classification:shortname,short description,priority
#

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

# NEW CLASSIFICATIONS
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: kickass-porn,SCORE! Get the lotion!,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

quick update : see http://lists.openinfosecfoundation.org/pipermail/discussion/2010-May/000411.html

Looks like it's either a barnyard2 issue, or a unified2 format issue

anything I can do to help ?
is there a way not to use barnyard2 and still log into a remote mysql server ?

If you enable the fast.log output as well, can you display some examples from that?

absolutely :

(I replaced my IP with a.b.c.d)

03/05/2011-20:00:49.301860  [**] [1:483:5] GPL SCAN PING CyberKit 2.2 Windows [**] [Classification: Misc activity] [Priority: 3] {ICMP} 178.79.0.148:8 -> a.b.c.d:0
03/05/2011-20:05:11.717533  [**] [1:498:6] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 3] {TCP} a.b.c.d:36198 -> 178.118.172.216:8025

Both alerts were logged as prio 3, the second one (Potentially Bad Traffic) should have been classified as priority 2

#cat /etc/suricata/classification.config | grep "Potentially" 
config classification: bad-unknown,Potentially Bad Traffic, 2

I put in place the current git master and it looks like the issue is fixed :

03/06/2011-10:39:55.491720  [**] [1:498:6] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 217.160.51.31:80 -> a.b.c.d:36543
03/06/2011-10:47:29.050479  [**] [1:498:6] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 217.160.51.31:80 -> a.b.c.d:45990

But... those events still get logged as priority 3 in snorby.
Is this because the snorby database is already populated with wrong info ?
Barnyard2 issue ?
anything else I can check ?

Could you as a test change the priority of the first entry in the classification.config to 1? I noticed that Suricata doesn't set the classification_id in unified2. This means it uses a value of 0 which maybe relates to the first entry. It's a long shot, but who knows :)

I edited classification.config and set the first entry to priority 1, and bounced suricata.

I triggered an event, which gets logged in fast.log :

03/06/2011-16:56:07.278935  [**] [1:498:6] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} a.b.c.d:50229 -> 178.118.172.216:8025
03/06/2011-16:56:48.624121  [**] [1:498:6] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 217.160.51.31:80 -> a.b.c.d:60276

Both alerts were logged as priority 3, not as 1 or 2

I also noticed that priority 1 events do get logged as priority 1... Just before I made the change, another event was logged :

03/06/2011-16:55:01.774535  [**] [1:2011565:1] ET WEB_SPECIFIC_APPS Dompdf dompdf.php input_file Parameter Remote File Inclusion Attempt [**] [Classification: Web Application Attack] [Priority: 1] {TCP} 190.0.162.210:53669 -> a.b.c.d:80

That one is displayed in snorby as severity high...

Hmmm did you restart Barnyard2 as well?

Does Snorby allow you to see the actual Snort/Suricata event priority?

hmmm yeah - I noticed newer events now get logged properly... I don't remember if I restarted barnyard2 or not earlier on
Let me test if for a few more days and see if it's fixed
tx

Hello everyone,

the patch provided by Victor, worked like a charm. No more severity 3 as default, http://twitpic.com/49tp2v

Best,

only for the records and future reference, this is the procedure that has worked for me, on the stable and on the beta.

wget http://www.openinfosecfoundation.org/download/suricata-1.0.2.tar.gz

tar xvfz suricata-1.0.2.tar.gz

cd suricata-1.0.2/src/

wget https://redmine.openinfosecfoundation.org/attachments/download/481/0001-Fix-priority-handling-during-the-signature-parsing-s.patch

patch < 0001-Fix-priority-handling-during-the-signature-parsing-s.patch

patching file detect-parse.c
Hunk #1 succeeded at 1386 (offset -100 lines).
Hunk #2 succeeded at 1463 (offset -96 lines).

cd ..

./configure
make
checkinstall