Local snort rules appear in Sguil but NOT Snorby

252 views
Skip to first unread message

bug...@gmail.com

unread,
Mar 21, 2015, 3:12:46 PM3/21/15
to securit...@googlegroups.com
Hi,

I have setup a test snort rule as follow in /etc/nsm/rules/local.rules

alert icmp 192.168.1.2 any -> any any (msg:"ICMP test"; sid:10000001;)

When I ping from 192.168.1.2 to anywhere (i.e.: google.com) I should get an event generated with the SID 10000001

In Sguil, I can see events being generated with the event message "ICMP Test" and the CNT grows as long as the ping is active.

So it looks it is working.

But what I don't understand is why I can't see those alerts in Snorby?
Snorby show me a lot of events (High, Medium and Low severity) but this "ICMP Test" never appears.

Am I missing something in how I created my local rules? don't local rules appear in snorby?

I have also made sure this SID is not in my threshold.conf, where I have my suppress rules to remove false positives. In this instance, I'd like to see those alerts!

I probably haven't constructed my local rule correctly, so if anyone knows what I am missing please help :)

Bugs.

Doug Burks

unread,
Mar 21, 2015, 3:19:53 PM3/21/15
to securit...@googlegroups.com
Hi Bugs,

When Snort fires an alert, barnyard should send it to to both Sguil and Snorby. Are you getting other new alerts in Snorby?  Can you attach the output of "sudo sostat-redacted"?
--
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at http://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.


--
Doug Burks
Need Security Onion Training or Commercial Support?
http://securityonionsolutions.com

bug...@gmail.com

unread,
Mar 21, 2015, 3:48:28 PM3/21/15
to securit...@googlegroups.com
On Saturday, March 21, 2015 at 7:19:53 PM UTC, Doug Burks wrote:
> Hi Bugs,
>
>
> When Snort fires an alert, barnyard should send it to to both Sguil and Snorby. Are you getting other new alerts in Snorby?  Can you attach the output of "sudo sostat-redacted"?
>
>

Hi Doug,

Sure I am happy to send you that, but when I try to attach a file to this reply I am getting an error...
I tried to rename this sostat output in .txt and even as a gzip file but it didn't work.
Is there another way for me to try sending you this text output? or I should just try later? (I can copy and paste but that's very long!)


Thanks.
Bugs.

bug...@gmail.com

unread,
Mar 21, 2015, 3:49:40 PM3/21/15
to securit...@googlegroups.com
Oh and yes, I am getting new alerts in snorby... usually it matches with sguil too.
I usually get a mail report from snorby every day... check the report, look at the event in snorby... and go to sguil if I want to look at the payload (export to wireshark)

Doug Burks

unread,
Mar 21, 2015, 3:59:04 PM3/21/15
to securit...@googlegroups.com
You could use a service like http://pastebin.com.

bug...@gmail.com

unread,
Mar 21, 2015, 4:19:13 PM3/21/15
to securit...@googlegroups.com
Actually, just tried from a different computer and it worked :)
Attached is the sostat log, hope it helps finding what is wrong.

Cheers,
Bugs.
sostat.txt.gz

Doug Burks

unread,
Mar 23, 2015, 12:19:22 PM3/23/15
to securit...@googlegroups.com
If you're not using the following services, please disable them:
* prads (sessions/assets)[ OK ]
* sancp_agent (SO-user)[ OK ]
* pads_agent (SO-user)[ OK ]
* argus[ OK ]
* http_agent (SO-user)[ OK ]
https://code.google.com/p/security-onion/wiki/DisablingProcesses

Syslog-ng isn't listening on port 514 (could be an issue):
Syslog-ng
Checking for process:
20134 supervising syslog-ng
20135 /usr/sbin/syslog-ng -p /var/run/syslog-ng.pid
Checking for connection:
nc: connect to localhost port 514 (tcp) failed: Connection refused

You have a large number of buffers in queue:
ELSA Buffers in Queue:
-rw-r--r-- 1 root root 6648 Mar 21 14:57
/nsm/elsa/data/elsa/tmp/buffers/1426949816.00246
-rw-r--r-- 1 root root 19441 Mar 21 14:56
/nsm/elsa/data/elsa/tmp/buffers/1426949755.99867
-rw-r--r-- 1 root root 74624 Mar 21 14:55
/nsm/elsa/data/elsa/tmp/buffers/1426949695.99446
-rw-r--r-- 1 root root 30887 Mar 21 14:54
/nsm/elsa/data/elsa/tmp/buffers/1426949635.99027
-rw-r--r-- 1 root root 88414 Mar 21 14:53
/nsm/elsa/data/elsa/tmp/buffers/1426949575.98571
-rw-r--r-- 1 root root 39992 Mar 21 14:52
/nsm/elsa/data/elsa/tmp/buffers/1426949515.93023
-rw-r--r-- 1 root root 8018 Mar 21 14:51
/nsm/elsa/data/elsa/tmp/buffers/1426949455.7173
-rw-r--r-- 1 root root 19749 Mar 21 14:50
/nsm/elsa/data/elsa/tmp/buffers/1426949395.6656
-rw-r--r-- 1 root root 40288 Mar 21 14:49
/nsm/elsa/data/elsa/tmp/buffers/1426949335.66069
-rw-r--r-- 1 root root 63193 Mar 21 14:48
/nsm/elsa/data/elsa/tmp/buffers/1426949275.64147
-rw-r--r-- 1 root root 31998 Mar 21 14:47
/nsm/elsa/data/elsa/tmp/buffers/1426949215.49496
-rw-r--r-- 1 root root 30217 Mar 21 14:46
/nsm/elsa/data/elsa/tmp/buffers/1426949155.4548
-rw-r--r-- 1 root root 52881 Mar 21 14:45
/nsm/elsa/data/elsa/tmp/buffers/1426949095.4497
-rw-r--r-- 1 root root 56967 Mar 21 14:44
/nsm/elsa/data/elsa/tmp/buffers/1426949035.32912
-rw-r--r-- 1 root root 389971 Mar 21 14:43
/nsm/elsa/data/elsa/tmp/buffers/1426948975.32414
-rw-r--r-- 1 root root 263968 Mar 21 14:42
/nsm/elsa/data/elsa/tmp/buffers/1426948913.84971
-rw-r--r-- 1 root root 55546 Mar 21 14:41
/nsm/elsa/data/elsa/tmp/buffers/1426948850.48367
-rw-r--r-- 1 root root 180888 Mar 21 14:40
/nsm/elsa/data/elsa/tmp/buffers/1426948786.45095
-rw-r--r-- 1 root root 59219 Mar 21 14:39
/nsm/elsa/data/elsa/tmp/buffers/1426948726.42079
-rw-r--r-- 1 root root 74 Mar 21 14:38
/nsm/elsa/data/elsa/tmp/buffers/1426948603.22053
-rw-r--r-- 1 root root 8352 Mar 21 14:36
/nsm/elsa/data/elsa/tmp/buffers/1426948543.16056
-rw-r--r-- 1 root root 468389 Mar 21 14:35
/nsm/elsa/data/elsa/tmp/buffers/1426948483.14179
-rw-r--r-- 1 root root 36 Oct 9 15:28
/nsm/elsa/data/elsa/tmp/buffers/host_stats.tsv
https://code.google.com/p/security-onion/wiki/FAQ#Why_does_sostat_show_a_high_number_of_ELSA_Buffers_in_Queue?

bug...@gmail.com

unread,
Mar 24, 2015, 8:23:41 AM3/24/15
to securit...@googlegroups.com
Thanks a lot Doug for your very detailed answer!
I will use this information for troubleshooting the issue. It might be worth mentioning as well that I have been running that SO instance for over a year, and did modify it a fair bit in that time with upgrades, update, additional packages, etc.
I will try to fix the issue anyway, so I can learn from it, but I am increasingly tempted to start afresh a new VM for a clean base.

Thanks again!
Bugs.
Reply all
Reply to author
Forward
0 new messages