SNMP's default OID access

Question

I have written a custom SNMPV2C agent (agentx protocol) extending netsnmp, As of now I am allowing view access to all in snmpd.conf as follows

view all included .1

it exposes mgmt (RFC1213 ) which looks fine, it also exposes snmpV2 mib's ( snmpMIB, snmpFrameworkMIB, VacmMIB etc).

I couldn't find any best practices document to detail that apart from opening our enterprise oid tree what all should be exposed, what are the security risks etc.

Answer 1

what are the security risks

With SNMP v2c, you have no encryption, nor signature. This means that Man-in-the-Middle attacks can both:

• leak data,
• change the content in a Set request, to trigger something indesirable on the target (for instance, you could reboot some targets this way).

Moreover, queries can be done over UDP, so the IP source address need not being correctly routed back to the source. Therefore, IP spoofing can be used to bypass IP ACLs and send SNMP Set requests to a target, from a fake IP source.

Note that with SNMP v3, all of these risks can be avoided.

So, either increase your security adding another network layer (IPsec for instance), or only do expose READ-ONLY OIDs with public content.

For instance, performance counters or basic configuration parameters like an IP address, a hostname, a counter, may be exposed. Maybe you should do a risk analysis to find which information can really be exposed.

At first, SNMP v1 was not secured at all. So, SNMP v2 has been proposed to add security, among other new features. But it was so much complicated, that the new security features have been removed, and the other features have been kept, and the protocol has finally been published with the name SNMP v2c. Finally, SNMP v3 has been created mainly to offer security features, but in a more easy way to implement than with SNMP v2.

Answer 2

Be extremely careful with blanket access (even read-only) on the entire ISO (.1) tree, especially if you use SNMPv3 USM for authentication and VACM for authorization.

The USM user database is exposed in the MIB itself (usmUserTable), so:

• With read-only access to it an adversary can simply walk the table and obtain all the valid principal (engine ID/username combination) values;
• With read-write access an adversary will be able to corrupt the stored authentication and/or privacy keys of random–or even all—users, causing denial of service. (For example, this can be done by running snmpusm(1) with garbage for old/new passphrases.)

Likewise, the VACM MIB contains access policy information, such as:

• Which SNMP context is locally available (vacmContextTable);
• Which USM user or SNMPv2c community maps to which VACM group (vacmSecurityToGroupTable);
• Which VACM group may access what portion(s) of the OID tree (vacmAccessTable and vacmViewTreeFamilyTable).

I do not think Net-SNMP allows read-write access to these VACM tables (the policy is taken from /etc/snmp/snmpd.conf and is not modified by the agent), but even read-only access may reveal too much information. For example, it may let an attacker figure out which USM user has access to the view in which the attacker is interested in and mount a password cracking attack on that specific USM user.

The SNMPv3 USM and VACM RFCs themselves explicitly warn you about how sensitive these tables are:

11.5  Access to the SNMP-USER-BASED-SM-MIB

   The objects in this MIB may be considered sensitive in many
   environments.  Specifically the objects in the usmUserTable contain
   information about users and their authentication and privacy
   protocols.  It is important to closely control (both read and write)
   access to these MIB objects by using appropriately configured Access
   Control models (for example the View-based Access Control Model as
   specified in [RFC3415]).

And:

7.4.  Access to the SNMP-VIEW-BASED-ACM-MIB

   The objects in this MIB control the access to all MIB data that is
   accessible via the SNMP engine and they may be considered sensitive
   in many environments.  It is important to closely control (both read
   and write) access to these to these MIB objects by using
   appropriately configured Access Control models (for example the
   View-based Access Control Model as specified in this document).

I would recommend explicitly excluding the USM and VACM MIBs at the minimum. Example:

view most included .1
view most excluded .1.3.6.1.6.3.15
view most excluded .1.3.6.1.6.3.16

Answer 3

Not adding to the general advice given in the answers before, I'd recommend to use snmpwalk -v2c -c community localhost .1 | your_pager to browse all the information you can see. Then decide what information you may not want to be seen.

For example on Linux you can typically see all processes and their arguments as well as disk devices and filesystems mounted.