SNMP blocking community string value 'public' and 'private'

[clopesda]

I would like to ask for some assistance/validation on a signature issue I’m facing right now.

The Customer tried to create an App-ID to identify and block any snmp traffic that has the Community String value of ‘public’ or ‘private’, and block snmp probes with those string values (not traps).

The App-ID didn’t work for obvious reasons (no context for snmp), and trying to create a vulnerability signature will lead me to the same problem, not to mention the 7 bytes limitation for ‘public’ that is one byte short, I tried some other community names to test but no dice, I believe that the missing context is responsible for this issue,  and to use the udp-unkown context would be wrong because the traffic is known as (snmp-base).

We did find an Snort signature offering the exact same thing:

alert udp $EXTERNAL_NET

any -> $HOME_NET 161 (msg:"SNMP public access udp"; content:"public"; 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:1411; rev:10;)

But due to our limitations I couldn’t replicate the signature, maybe because I’m missing something and that’s why I would like to reach out to all of you.

Do we have a workaround for this?

Can we have a specific context for snmp created or some kind of contentless regex adoption?

What solutions could be offered (if any) at this moment?

I highly appreciate any assistance,

Thanks,

Claudio

[mharman · Accepted solution]

So at this moment, no solution.  And yes you can ask for contexts to be exposed they can update it through the App-ID process so normally it will not take as long as a feature request.