Posted by: Eric Siegel
A question recently arose about best practices for SNMP
security, so I feel that a quick blog entry about it would be useful.
Here is the simple rule: if you're running SNMP version 1 or
SNMP version 2c (the current variant of SNMP version 2; the original version
was abandoned because of a flawed security system), then there isn't any
security. So don't allow anyone to write to your devices using SNMP, period.
Completely disable all facilities on the devices that respond to SNMP write
(SET) commands. If you have to write to the devices, then use a secure pathway,
such as secure shell (SSH) or a secure XML flow, thereby avoiding SNMP entirely
for writing.
For reading/GET functions in SNMPv1 and v2, I'd just give up
and allow unencrypted community strings and data, but I still might secure the
aggregated data in collectors or a central management platform. I'd use TCP and
encryption for all communications between management platforms and between
management platforms and SNMP collectors/pollers. I'd disallow any use of SNMP
to sniff traffic, because that might reveal user passwords, etc. (And such
sniffing is inefficient and awkward anyway!) I'd also see if I could restrict
the data sent by sensitive devices (e.g., firewalls) in response to GET
commands; e.g., I'd might not let them send their version numbers or
configuration data.
An intruder could do a denial-of-service attack by issuing
an overwhelming number of read/GET commands to an SNMPv1 or v2 device under
these rules, so maybe you should require that devices have a way to throttle
incoming SNMP requests to ensure that they aren't overwhelmed. (Many devices do
this by ensuring that SNMP processes run at a relatively low priority.)
Having devices and the management agent check IP addresses
and hostnames is not a guarantee against intruders, although it makes intrusion
more difficult. Therefore, to decrease the probability of an attack on managed
devices, the managed devices should be configured to accept commands only from
sources in designated subnets (e.g., a management subnet) or from designated IP
addresses or address ranges.
And, of course, you must ensure that devices do not include
"hidden" community strings (i.e., strings that are embedded in the
device, are typically used by the manufacturer, and are usually undocumented
and not revealed to the enterprise purchaser of the equipment); these can
create severe vulnerabilities.
You should have firewalls block all SNMP commands that are
incoming to protected areas. Use remote collectors/pollers to gather SNMP data
and push it through the firewall on a secure TCP flow if you have to go through
a firewall.
SNMP version 3 is the most secure, robust solution. Unfortunately,
its security features use a new security model that was designed to be
independent of other security infrastructures. That helped ensure that SNMPv3 could
function in a broken network, but the complexity has made many organizations
reluctant to deploy SNMPv3. The IETF's isms Working Group is now trying to create an SNMPv3 security
model based on SSH over TCP. When it becomes commercially available, the
Integrated Security Model for SNMP will be the recommended security solution for SNMPv3.
Comments