3

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.

DevC
  • 7,055
  • 9
  • 39
  • 58

3 Answers3

3

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.

Alexandre Fenyo
  • 4,526
  • 1
  • 17
  • 24
  • Thanks, we will migrate to SNMP v3 in next release, for this release we are only allowing read only access. .. but I am mainly worried about the default modules ( what all I should enable or disable) .. for now with view all .1. I see RFC1213 and SNMPV2 (1.3.6.1.6.3.X) is exposed.. are there any security risk with read-only access to these modules? – DevC Sep 18 '17 at 11:28
  • The MIB-2 OIDs, when read-only, do not imply specific security risks: they contain only basic informations. But sharing some basic information may be considered by some people a risk: for instance, publishing you MAC address can leak informations to remote hosts, far from your local Ethernet network (on your local network, this information is, of course, public). And your local MAC address is a piece of information that can help discovering the manufacturer of your server. And knowing this manufacturer, an attacker can try some public vulnerabilities of their servers... – Alexandre Fenyo Sep 18 '17 at 11:39
  • So, it is not specifically dangerous, but depending on the way of dealing with threats, some people may not want this information to be public. – Alexandre Fenyo Sep 18 '17 at 11:41
  • Thanks it some what answer my question, but are there are any best practices or any rule that minimum I should allow default modules? If customers are using custom NMS then it should not break for them. Like they may need how many get request have been made, our enterprise OID from sys module etc. – DevC Sep 18 '17 at 12:18
  • 1
    The best practice with SNMP v2c and MIB-2 is to wide-open it **read-only**, and the access must be restricted both with an IP access control list and a non default community string. – Alexandre Fenyo Sep 18 '17 at 12:22
3

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
Community
  • 1
  • 1
astralblue
  • 83
  • 4
0

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.

U. Windl
  • 3,480
  • 26
  • 54