Suppression not working (sid:2101411 - GPL SNMP public access udp) for specific IPs

[Tom]

Dear all,

first of all, I am sorry if this topic has been brought up yet in any way.
So far I haven't found anything that would help me out in this case.

As many if you for sure know, this specific rule is triggering on many
false/positives. I have yet set various suppressions on this rule and they
all work - except for one specific session.

suppress gen_id 1, sig_id 2101411, track by_dst, ip 192.168.xx.x

After I have edited the threshold.conf I perform
"sudo nsm_sensor_ps-restart --only-snort-alert"
to restart the snort sensors and apply the suppression.

What I have tried so far:
* suppressing by_dst
* suppressing by_src
* suppressing the hole alert (for testing)
* Adding the source subnet to #HOME_NET in snort.conf

What I haven't done:
Like described in https://code.google.com/p/security-onion/wiki/ManagingAlerts I could create a local rule for that alert, classifying the dst IP in the $OVERACTIVE variable, but I would definately like to find out, why the suppression is not working.

The rule mentioned:

alert udp $EXTERNAL_NET any -> $HOME_NET 161 (msg:"GPL SNMP public access udp"; content:"public"; fast_pattern:only; reference:bugtraq,2112; reference:bugtraq,4088; reference:bugtraq,4089; reference:cve,1999-0517; reference:cve,2002-0012; reference:cve,2002-0013; classtype:attempted-recon; sid:2101411; rev:12;)

I highly appreciate any ideas, sorry if I left out necessary information.

Best wishes,
Tom

[BBCan177]

Hi Tom,

I have that SID added to my Disabled file in

[ /etc/nsm/pulledpork/disabledsid.conf ]

# GPL SNMP public access UDP
1:2101411

Did you add the suppression to the following file?

[ /etc/nsm/{ Sensor Interface folder }/threshold.conf ]

[Shane Castle]

Forgive me if this seems nitpicking, but IMHO that is not a FP but
rather indicates exactly what it says, that there was an attempted recon
from outside to your SNMP ports. In my last setup, this should never
have happened, since I blocked 161/udp eitherbound at the firewall, and
so I was really interested in any hits that came from that rule. That
said, if you don't block SNMP inbound (and why not?), this could indeed
be a very chatty rule. If you never want to see it displayed then
/etc/nsm/pulledpork/disablesid.conf is where to stop it. If you want to
throttle it then /etc/nsm/rules/threshold.conf is the spot. And you
don't really have SNMP-aware devices that use the "public" community
string, do you? Please tell me you don't.

(IDS philosophical rant deleted.)

--
Mit besten Grüßen
Shane Castle

[Tom]

Hello Shane Castle, hello BBCan177 thank you for your reply!
The network I am talking about is definately a home network (we got many different ones) and the attempt to access the public community string is definately a false-positive in this case.
So I simply want to suppress it, not disable the SID in the disablesid.conf.
@BBCan117: I am definately using the correct threshold.conf, as I have configured a hundred suppressions yet and all of them are working, except for this single one.

Thanks for taking your time!

Regards,
Tom

[Heine Lysemose]

Hi

Have you tried, sudo rule-update, after you have updated the threshold.conf file?

Regards,
Lysemose

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

[Shane Castle]

OK, here comes the (partial) IDS philosophy rant.

First, there are good reasons why you should disable rules rather than
suppress them, the primary one being that you are preventing your IDS
from doing the work of looking for the alert at all. This saves on
storage, CPU, and I/O. The only reason I ever used the suppress in
threshold.conf was if there was no other way to stop the alert, such as
those generated through some Snort preprocessors.

Second, if these alerts are not being suppressed, it's probably because
the IP address is not matching your suppress criteria, or the sid isn't
correct. You haven't shown us the alert you are actually getting
(including IP addresses), just the rule, so if your "suppress" line in
threshold.conf is incorrectly defined we won't catch it. Remember,
"track by_dst" pays no attention to the source IP address.

Third, IMO your internal and external nets are not correctly defined if
this rule is firing and it's a true FP. What are your definitions for
$EXTERNAL_NET and $HOME_NET? Remember, the default for $EXTERNAL_NET is
"any", which means that it will include $HOME_NET, regardless of what
that is set to. This may not be what you want. Some people define
$EXTERNAL_NET to be the negation of the one for $HOME_NET, for just this
reason.

--
Mit besten Grüßen
Shane Castle

[Tom]

@Lysemose:

I have, thanks though!

@Shane Castle:

I appreciate your rant :-) As you mentioned earlier, this Alert is definately an interesting and important one and I fully agree, so by my understanding it would be better to suppress a specific case.
Sadly I am forced to not show the full IP addresses, but I can for sure say that these are correct.

Entry copied out of Threshold.conf:
suppress gen_id 1, sig_id 2101411, track by_dst, ip 192.168.xx.2

Event copied out of Snorby:
Sensor1 192.168.xx.1 192.168.xx.2 GPL SNMP public access udp 6:17 PM
Generator ID Sig. ID Sig.
1 2101411 12

You are definately right about negating $HOME_NET instead of "any" for $EXTERNAL_NET and I will change it asap. Am I correct that a suppression should work regardless of this setting?
Also, even though by_dst pays no attention to by_src, if I suppress either, it should suppress this specific event occuring for the mentioned by_dst IP, shouldn't it? (Not considering which way might be more intelligent in my specific case)

I highly appreciate your help, thanks a lot!

Have a good time,
Tom