Project

General

Profile

Actions

Bug #275

closed

Alert classification issue ?

Added by Peter VE over 11 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

I have set up suricata 1.1 beta1, barnyard2, logging events into snorby.
Everything works well, but I noticed that all events are logged as "low severity".

I replaced suricata with snort, used the same barnyard2 engine, sending events into the same snorby instance.
In that configuration, events are classified correctly.

Is this a known issue ? Any way I can troubleshoot/fix this myself ?


Files

Actions #1

Updated by Victor Julien over 11 years ago

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?

Actions #2

Updated by Peter VE over 11 years ago

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

Actions #3

Updated by Peter VE over 11 years ago

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 ?

Actions #4

Updated by Victor Julien over 11 years ago

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

Actions #5

Updated by Peter VE over 11 years ago

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
Actions #6

Updated by Victor Julien over 11 years ago

Can you try the attached patch or just the current git master? I believe I got the issue fixed.

Actions #7

Updated by Peter VE over 11 years ago

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 ?

Actions #8

Updated by Victor Julien over 11 years ago

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 :)

Actions #9

Updated by Peter VE over 11 years ago

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

Actions #10

Updated by Victor Julien over 11 years ago

Hmmm did you restart Barnyard2 as well?

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

Actions #11

Updated by Peter VE over 11 years ago

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

Actions #12

Updated by Phillip Bailey over 11 years ago

Hello everyone,

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

Best,

Actions #13

Updated by Victor Julien over 11 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 70 to 100

Considering this bug fixed. Thanks guys.

Actions #14

Updated by Phillip Bailey over 11 years ago

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

Actions

Also available in: Atom PDF