Problems Tuning GPL SNMP Public Access UDP

[mmfirm...@gmail.com]

I followed the steps to tune the "GPL SNMP Public Access UDP" which seems to be problematic in general as it's the topic in the alerts FAQ.

What's interesting is an IP I listed in the var OVERACTIVE variable still generates these alerts when their originate from a different source IP. This is interesting behavior as I assumed putting the non-existent IP in the newly created rule would eliminate it altogether in the new rule.

I realize and have notified operations that this may represent a misconfiguration situations.

Is there any way to tune the threshold?

Thanks to everyone and especially Doug for the most awesome NSM machine ever created!

[Kevin Branch]

Did you define $OVERACTIVE in the appropriate snort/suricate config file and then add a line into modifysid.conf to change the target IP from "any" to "!$OVERACTIVE", followed by running rule-update?  

When you examine the end result of pulledpork applying modifysid.conf to your ruleset (/etc/nsm/rules/downloaded.rules), do you see your "GPL SNMP Public Access UDP" having actually been changed?

Are you quite sure that the problem alerts you saw after your initial rule tuning, actually were triggered after you ran rule-update rather than before?

If you sill haven't solved this issue, please show us what you put in modifysid.conf and what specific snort or suricata config file changed (specific path please) as well as what you added to that file (OVERACTIVE definition I presume).

Kevin

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

[mmfirm...@gmail.com]

I followed this FAQ:
https://github.com/Security-Onion-Solutions/security-onion/wiki/ManagingAlerts

And I did the procedure to retire the old rule altogether and put in a new rule. I guess within the instructions I am looking for the filter (reg-ex?) to essentially tell it disregard all GPL SNMP alerts to the IP in question.

I am sort of on the fence about this as it it maybe kicking them out becuase of a configuration.

[Kevin Branch]

If after running rule-update, the output from

 grep -i "SNMP public access udp" /etc/nsm/rules/downloaded.rules

does not have a # at the beginning of the rule you were trying to retire, then you have a problem in /etc/nsm/pulledpork/disablesid.conf.  

To disable the specific rule you mentioned, you should put this one liner in that file:

1:2101411

or use this line to get the udp and tcp version of that rule

pcre:SNMP public access

If you need more help, report whether or not the old rule is confirmed to be disabled, and then share what your replacement rule looks like.  

Kevin

[mmfirm...@gmail.com]

I have multiple sensors does this need to be done on each sensor?

On Monday, May 11, 2015 at 9:02:33 AM UTC-4, Kevin Branch wrote:
> If after running rule-update, the output from
>

>  grep -i "SNMP public access udp" /etc/nsm/rules/downloaded.rulesdoes not have a # at the beginning of the rule you were trying to retire, then you have a problem in /etc/nsm/pulledpork/disablesid.conf.  

[Kevin Branch]

I haven't yet done a distributed deployment but I believe that by default, rule downloading and processing with PulledPork is all done at the SO server level rather than separately on each sensor.

Kevin

[mmfirm...@gmail.com]

I checked the sensors, and noticed that while it was disabled on the SO server, it was not on the Sensors, so I manually disabled it on the sensors (3).

In larger deployments I remember there was a tool which automatically manages large numbers of sensors.

[Doug Burks]

You shouldn't have to manually disable rules on sensors as sensors
should copy the ruleset from the master server. If you're running the
traditional rule-update mechanism, sensors will copy the ruleset from
the master daily at 7:06 AM UTC. If you're running salt, then sensors
copy the ruleset from the master server every 15 minutes.

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

[mmfirm...@gmail.com]

That's interesting, because for some reason it didn't.

On Wednesday, May 13, 2015 at 8:38:40 PM UTC-4, Doug Burks wrote:
> You shouldn't have to manually disable rules on sensors as sensors
> should copy the ruleset from the master server. If you're running the
> traditional rule-update mechanism, sensors will copy the ruleset from
> the master daily at 7:06 AM UTC. If you're running salt, then sensors
> copy the ruleset from the master server every 15 minutes.
>

[Doug Burks]

Are your sensors running salt or the traditional rule-update mechanism?

What is the output of the following command on your sensors?
grep LOCAL_NIDS_RULE_TUNING /etc/nsm/securityonion.conf

[mmfirm...@gmail.com]

Here you go, it's attached.

Is it worth while to setup salt for three sensors? If so, is there an FAQ?

Thanks Doug!

On Thursday, May 14, 2015 at 6:53:30 PM UTC-4, Doug Burks wrote:
> Are your sensors running salt or the traditional rule-update mechanism?
>
> What is the output of the following command on your sensors?
> grep LOCAL_NIDS_RULE_TUNING /etc/nsm/securityonion.conf
>

[Doug Burks]

Replies inline.

On Fri, May 15, 2015 at 9:04 AM, <mmfirm...@gmail.com> wrote:
> Here you go, it's attached.

Is that screenshot from a sensor?

Is that screenshot the whole output? Just 5 lines and all 5 lines
commented out?

Try editing /etc/nsm/securityonion.conf on the sensor and adding a
line like the following (without the comment mark):
LOCAL_NIDS_RULE_TUNING=no

Then run "sudo rule-update" on the sensor and see if it copies the
rules from the server to the sensor. If not, please send all output
from the command (redacting sensitive info as necessary).

> Is it worth while to setup salt for three sensors? If so, is there an FAQ?

Please see:
https://github.com/Security-Onion-Solutions/security-onion/wiki/Salt#salting-an-existing-deployment