Snorby not showing events or alerts

[Brad]

Sguil is seeing alerts but not Snorby. I've attached a file with the output from sostat. I generate some traffic and I see the snort.unified2 file increase in size.

Not sure what is the problem.

Thanks,
Brad

[Doug Burks]

Hi Brad,

Replies inline.

On Fri, Nov 14, 2014 at 3:10 PM, Brad <bradm...@gmail.com> wrote:
> Sguil is seeing alerts but not Snorby. I've attached a file with the output from sostat.

Feedback:

- when posting to a public forum, please use sostat-redacted, which
will automatically redact any IPv4/IPv6/MAC addresses. There may be
additional sensitive info that you still need to redact manually.

- if you're not using the following services, disable them:
* prads (sessions/assets)[ OK ]
* sancp_agent (sguil)[ OK ]
* pads_agent (sguil)[ OK ]
* argus[ OK ]
* http_agent (sguil)[ OK ]
https://code.google.com/p/security-onion/wiki/DisablingProcesses

- eth0 - eth3 are only showing 739 packets received. Seems rather
small. Is that correct?

- 40GB disk seems rather small:
/dev/sda1 39G 6.2G 31G 17% /

- 4GB RAM seems rather small:
Mem: 4046400k total, 3701864k used, 344536k free, 17540k buffers


> I generate some traffic

What kind of traffic?

> and I see the snort.unified2 file increase in size.

What rule should be alerting on the traffic?

Is it possible that Snorby is not displaying the alert as a new row on
the Events tab, but simply incrementing the count on an existing
event?


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

[Brad]

On Friday, November 14, 2014 3:22:08 PM UTC-5, Doug Burks wrote:
> Hi Brad,
>
> Replies inline.
>

> On Fri, Nov 14, 2014 at 3:10 PM, Brad wrote:
> > Sguil is seeing alerts but not Snorby. I've attached a file with the output from sostat.
>
> Feedback:
>
> - when posting to a public forum, please use sostat-redacted, which
> will automatically redact any IPv4/IPv6/MAC addresses. There may be
> additional sensitive info that you still need to redact manually.
>
> - if you're not using the following services, disable them:
> * prads (sessions/assets)[ OK ]
> * sancp_agent (sguil)[ OK ]
> * pads_agent (sguil)[ OK ]
> * argus[ OK ]
> * http_agent (sguil)[ OK ]
> https://code.google.com/p/security-onion/wiki/DisablingProcesses

Thanks for the heads-up about sostat-redacted, however, there's nothing sensitive in the sostat output.

>
> - eth0 - eth3 are only showing 739 packets received. Seems rather
> small. Is that correct?

Yes, I am running SO in a VM set to host only with a couple other VMs for traffic generation. I've been using hping3 to generate the traffic to trigger an alert.

>
> - 40GB disk seems rather small:
> /dev/sda1 39G 6.2G 31G 17% /
>

The SO VM is meant to monitor traffic in a 12-person classroom for a two day period and then will be reverted to it's initial state so I'm hoping that will be enough space. I'll find out after the first class.

> - 4GB RAM seems rather small:
> Mem: 4046400k total, 3701864k used, 344536k free, 17540k buffers
>

Do you think this is causing the Snorby issue? If so i can up the RAM.

> > I generate some traffic
>
> What kind of traffic?

hping3 traffic generated from a Kali VM. I'm am getting alerts in Sguil so I know the hping3 syntax is correct.

>
> > and I see the snort.unified2 file increase in size.
>
> What rule should be alerting on the traffic?
>
> Is it possible that Snorby is not displaying the alert as a new row on
> the Events tab, but simply incrementing the count on an existing
> event?

I don't believe so but I've attached a pic of my Snorby dashboard and events.

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

Thanks,
Brad

[Doug Burks]

Replies inline.

On Fri, Nov 14, 2014 at 3:51 PM, Brad <bradm...@gmail.com> wrote:
>> - 4GB RAM seems rather small:
>> Mem: 4046400k total, 3701864k used, 344536k free, 17540k buffers
>>
>
> Do you think this is causing the Snorby issue? If so i can up the RAM.

Not necessarily, but you're already using swap space, so I'd
definitely recommend increasing.

>> > I generate some traffic
>>
>> What kind of traffic?
>
> hping3 traffic generated from a Kali VM. I'm am getting alerts in Sguil so I know the hping3 syntax is correct.
>
>>
>> > and I see the snort.unified2 file increase in size.
>>
>> What rule should be alerting on the traffic?
>>
>> Is it possible that Snorby is not displaying the alert as a new row on
>> the Events tab, but simply incrementing the count on an existing
>> event?
>
> I don't believe so but I've attached a pic of my Snorby dashboard and events.

Have you verified that your barnyard2.conf files in
/etc/nsm/HOSTNAME-INTERFACE/ still have a line like this to send to
Snorby?
output database: alert, mysql, user=root dbname=snorby host=127.0.0.1
disable_signature_reference_table

Have you checked your barnyard2 log files in
/var/log/nsm/HOSTNAME-INTERFACE/ for any additional clues?

[Brad]

On Friday, November 14, 2014 4:11:18 PM UTC-5, Doug Burks wrote:
> Replies inline.
>

> On Fri, Nov 14, 2014 at 3:51 PM, Brad wrote:
> >> - 4GB RAM seems rather small:
> >> Mem: 4046400k total, 3701864k used, 344536k free, 17540k buffers
> >>
> >
> > Do you think this is causing the Snorby issue? If so i can up the RAM.
>
> Not necessarily, but you're already using swap space, so I'd
> definitely recommend increasing.

Thanks, I will.

> >> > I generate some traffic
> >>
> >> What kind of traffic?
> >
> > hping3 traffic generated from a Kali VM. I'm am getting alerts in Sguil so I know the hping3 syntax is correct.
> >
> >>
> >> > and I see the snort.unified2 file increase in size.
> >>
> >> What rule should be alerting on the traffic?
> >>
> >> Is it possible that Snorby is not displaying the alert as a new row on
> >> the Events tab, but simply incrementing the count on an existing
> >> event?
> >
> > I don't believe so but I've attached a pic of my Snorby dashboard and events.
>
> Have you verified that your barnyard2.conf files in
> /etc/nsm/HOSTNAME-INTERFACE/ still have a line like this to send to
> Snorby?
> output database: alert, mysql, user=root dbname=snorby host=127.0.0.1
> disable_signature_reference_table

output database: alert, mysql, user=root dbname=snorby host=127.0.0.1

output alert_syslog: LOG_LOCAL6 LOG_ALERT

I have the above in my barnyard2.conf file but I don't have the "disable_signature_reference_table" entry. I just read your blog pertaining to disable_signature_reference_table but I'm unable to determine if it's relevant to my problem.

> Have you checked your barnyard2 log files in
> /var/log/nsm/HOSTNAME-INTERFACE/ for any additional clues?
>

I've attached the barnyard log file but nothing jumps out at me.

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

Thanks,
Brad

[Doug Burks]

barnyard2.conf should have "disable_signature_reference_table".

Are you running the latest ISO image?

Have you installed all updates?

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

[Brad]

On Friday, November 14, 2014 4:36:45 PM UTC-5, Doug Burks wrote:
> barnyard2.conf should have "disable_signature_reference_table".

OK, I will add it.

> Are you running the latest ISO image?
>
> Have you installed all updates?

I ran soup earlier today.

[Doug Burks]

On Fri, Nov 14, 2014 at 4:46 PM, Brad <bradm...@gmail.com> wrote:
> On Friday, November 14, 2014 4:36:45 PM UTC-5, Doug Burks wrote:
>> barnyard2.conf should have "disable_signature_reference_table".
>
> OK, I will add it.

You shouldn't need to manually add it, the updated NSM scripts should
have updated it for you.

>> Are you running the latest ISO image?

Which ISO image were you running?

>> Have you installed all updates?
>
> I ran soup earlier today.

Did you restart services and/or reboot after running soup?

[Brad]

On Friday, November 14, 2014 4:49:27 PM UTC-5, Doug Burks wrote:

> On Fri, Nov 14, 2014 at 4:46 PM, Brad wrote:
> > On Friday, November 14, 2014 4:36:45 PM UTC-5, Doug Burks wrote:
> >> barnyard2.conf should have "disable_signature_reference_table".
> >
> > OK, I will add it.
>
> You shouldn't need to manually add it, the updated NSM scripts should
> have updated it for you.
>

By NSM scripts are you referring to SOUP?

> >> Are you running the latest ISO image?
>
> Which ISO image were you running?
>

I'mnot sure which ISO version was used to create the VM. Not sure how to determine that. Is there a command I can run to find that out?

> >> Have you installed all updates?
> >
> > I ran soup earlier today.
>
> Did you restart services and/or reboot after running soup?
>

Yes, I have rebooted several times since I ran SOUP.

Thanks,
Brad

[Doug Burks]

Replies inline.

On Sun, Nov 16, 2014 at 7:17 AM, Brad <bradm...@gmail.com> wrote:
> On Friday, November 14, 2014 4:49:27 PM UTC-5, Doug Burks wrote:
>> On Fri, Nov 14, 2014 at 4:46 PM, Brad wrote:
>> > On Friday, November 14, 2014 4:36:45 PM UTC-5, Doug Burks wrote:
>> >> barnyard2.conf should have "disable_signature_reference_table".
>> >
>> > OK, I will add it.
>>
>> You shouldn't need to manually add it, the updated NSM scripts should
>> have updated it for you.
>>
>
> By NSM scripts are you referring to SOUP?

No, I'm referring to the following code in /usr/sbin/nsm_sensor_ps-start:

if ! grep disable_signature_reference_table
$BARNYARD2_CONFIG >/dev/null 2>&1; then
sed -i 's|output database: alert, mysql,
user=root dbname=snorby host=127.0.0.1|output database: alert, mysql,
user=root dbname=snorby host=127.0.0.1
disable_signature_reference_table|g' $BARNYARD2_CONFIG
fi

After installing the updates from
http://blog.securityonion.net/2014/06/new-barnyard2-nsm-rule-update-and.html,
the next time barnyard2 was (re)started, that could should have
updated the config file.

>> >> Are you running the latest ISO image?
>>
>> Which ISO image were you running?
>>
>
> I'mnot sure which ISO version was used to create the VM. Not sure how to determine that. Is there a command I can run to find that out?

When was the VM created?

>> >> Have you installed all updates?
>> >
>> > I ran soup earlier today.
>>
>> Did you restart services and/or reboot after running soup?
>>
>
> Yes, I have rebooted several times since I ran SOUP.

If all else fails, you can always rebuild the VM.