SNMP's default OID access

user_973699 0
Viewed 1766

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.

snmpv2c net-snmp snmp
3 Answers

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
user_32426130

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.

user_66074970
Related